[This Transcript is Unedited]

NATIONAL COMMITTEE ON VITAL AND HEALTH STATISTICS

SUBCOMMITTEE ON STANDARDS

ADMINISTRATIVE SIMPLIFICATION UNDER

THE PATIENT PROTECTION AND AFFORDABLE CARE ACT

THE ACKNOWLEDGMENT TRANSACTION STANDARD AND MAINTENANCE

AND MODIFICATIONS TO STANDARDS AND OPERATING RULES

(THE PRESENT AND THE FUTURE)

April 27, 2011

Marriott Washington Hotel
1221 22nd Street, NW
Washington, DC 20001

Proceedings by:
CASET Associates, Ltd.
Fairfax, Virginia 22030
(703) 266-8402

CONTENTS

PROEEDINGS

Agenda Item: Call to Order, Welcome, Introductions, Walter Suarez

DR. SUAREZ: Okay, I think we’re going to go ahead and get started. Good morning everyone. We’re going to convene this hearing of the National Committee on Vital and Health Statistics Subcommittee on Standards. We’ll do introductions around the table and then in the audience very briefly in a second, and I think we do have people on the phone as well as on the web, so we’ll go to the members on the phone to introduce themselves in just a minute.

I just wanted to mention our hearing today, as you probably have seen from the agenda, has been divided into two parts. The morning will be devoted to a discussion on the acknowledgements transactions, the various transactions associated with acknowledgements of receipt of other transactions, and so we have a series of panels to talk about their perspectives. We have asked them four or five questions around acknowledgements, which are the primary purposes and uses, the benefits, which are the transactions that are important to establish as a minimum set of acknowledgement transactions that would be expected to be implemented by the industry, and which might be other acknowledgement transactions that might be adopted in a voluntary way, and what are the standards for those transactions and the operating rules that would be expected or needed to implement successfully those transactions. So that’s the morning part.

In the afternoon, we have devoted the afternoon to a series of discussions around the maintenance and modifications of standards and operating rules. We are certainly new to the process of operating rules. We have only been in this for several months in terms of structuring the way they would be implemented, developed and implemented. And then we wanted to have this hearing this afternoon to talk about how the process is going, what are the methods and mechanisms and processes established by standards development organizations to maintain those standards and to change those standards as well as what are their perspectives from the operating rule authoring organizations and the industry in general, and how the two relate, and into the future what are some of the ways in which we can improve the process of developing and reviewing and adopting and then implementing those operating rules and how again they relate to the standards development process.

So those are the two sessions for today, and so we’re going to go around first and introduce the members of the Committee around the table and the leads from the various agencies. We’ll go then to the phone to introduce any members, and then we’ll go to the public around the table. My name is Walter Suarez and I am one of the Co-Chairs of the Subcommittee on Standards and a member of the Committee and I don’t have any conflict.

DR. WARREN: I’m Judy Warren from the University of Kansas School of Nursing. I’m the other Co-Chair of the Standards Subcommittee and a member of NCVHS, and I have no conflicts.

DR. SCANLON: I’m Bill Scanlon from the National Health Policy Forum. I’m a member of the Subcommittee and have no conflicts.

MS. GREENBERG: Good morning, I’m Marjorie Greenberg from the National Center for Health Statistics, CDC, and Executive Secretary to the Committee.

MS. MILLER: My name is Lisa Miller. I am the Chair of X12C Communications and Control, and also the CIO for Xeohealth.

MS. WEIKER: I’m Margaret Weiker. I’m Product Director at Hewlett Packard and Chair of the X12N Insurance Subcommittee.

MS. WILSON: Hi, I’m Nicole Wilson. I’m replacing Jorge Ferrera and I’m from Veterans Health Affairs and Office of Health Information.

MS. WILLIAMSON: Michelle Williamson with CDC’s National Center for Health
Statistics and staff to the Subcommittee.

MS. BUENNNING: Denise Buenning, Director of the Administrative Simplification Group at CMS’s office of E-Health Standards and Services, and sitting in as lead staff to the Subcommittee for the vacationing Lorraine Doo.

DR. SUAREZ: Let the record note that Lorraine is in spirit with us today,
right?

MS. BUENNING: Yes, she is.

MR. BILBREY: Good morning, I’m Doug Bilbrey from the SSI Group.

MS. HOLLAND: Priscilla Holland, NACHA.

MS. FOERSTER: Rachel Foerster on behalf of CAQH.

MR. LAZARUS: Steve Lazarus on behalf of CAQH.

MR. AFANO: Bill Afano, Blue Cross Blue Shield Association.

MS. THORNTON: Jeanette Thornton, America’s Health Insurance Plans.

MS. JACKSON: Debbie Jackson, National Center for Health Statistics, Committee staff.

MS. GARR: Kari Garr, CMS.

MS. WETZEL: Shannon Wetzel, CMS.

MR. ALBRIGHT: Matthew Albright, CMS.

MS. WHEELER: Gladys Wheeler, CMS.

MS. SKAHAIT(?): Chris Skahait, CMS.

MR. KILPATRICK: Sean Kilpatrick, Availity.

MR. SCANTLAND: Matt Scantland, with CoverMyMeds.

MS. GABEL: Annette Gabel, Medco Health Solutions, representing NCPDP today.

MS. DAVIDSON: Michelle Davidson, Walgreens.

MR. WHICKER: Jim Whicker, Kaiser Permanente, representing WEDI.

MS. DARST: Laurie Darst, Mayo Clinic, representing the Minnesota Administrative Uniformity Committee.

MS. KOCHER: Gail Kocher, Blue Cross Blue Shield Association.

MR. SCHUPING: Jim Schuping, with WEDI.

MR. KLIMEK: John Klimek, NCPDP.

MS. GILBERTSON: Lynne Gilbertson, National Council for Prescription Drug Programs.

MR. BARBOUR: Robert Barbour, American Medical Association.

MS. BANKS: Tammy Banks, AMA.

MS. ZASATURIAN(?): Lee Zasaturian, AMA.

MR. TENNANT: Rob Tennant, Medical Group Management Association.

MR. WALKER: Peter Walker, Aetna.

MR. FISHER: Greg Fisher, United Healthcare.

DR. SUAREZ: Are there any members on the Committee or the Subcommittee on the phone?

DR. CHANDERRAJ: Yes, Raj Chanderraj.

DR. SUAREZ: Anyone else? Okay, we’re going to go ahead and get started. Our first session in the morning is really to take a look at acknowledgements in general and in what kind of transactions exist, really, to acknowledgements, and what kind of standards, and then operating rules, are in existence or are needed to implement with this acknowledgements transaction. So we appreciate very much, first of all, everyone that is going to be presenting and providing testimony today, and those that submitted testimony in writing, for taking the time to do so. And so we will go to our first presenter. I think Margaret, you’re first?

Agenda Item: Part 1 – Standard Transactions for Acknowledgements.

Session 1.1: Overview of acknowledgements (in plain language) and perspectives from standards organizations and operating rules entities, Margaret Weiker, X12, Mike Cabral, CMS (written), Lisa Miller, X12, Annette Gabel, NCPDP, Gwen Lohse, CAQH CORE.

MS. WEIKER: Good morning. I’m still Margaret Weiker and I’m going to give an overview. I was asked to provide an overview in plain English, so as plain as I can make it, maybe with a little bit of a Texas twang and I’ll try not to use Texas terms, talk about acknowledgements.

So a little bit about X12. We are an ANSI-accredited standards organization that was chartered more than 30 years ago. We develop EDI standards, technical reports, which you all may know as implementation guides. We also have reference models, and we also produce XML schema. We are a cross-industry standards development organization. Insurance, which healthcare falls under, is just one of the many subcommittees that X12 has. We have subcommittees on transportation, finance, government, supply chain, as well as other industries.

When I looked up the word “acknowledgement” and I used many sources to come up with a definition of what is an acknowledgement. So I’ve listed five definitions that I found in regard to what is an acknowledgment, and the one I want to focus on is the third one, because that’s what we’re talking about when we’re talking about the X12 standards. We’re talking about an answer or a response in return for something done. So in plain English, that’s what we’re talking about, is you’re going to respond to something that was done.

So X12 has several acknowledgement standards. The ones that are highlighted in red are the ones that was included on the X12 submission of the DSMO request, the Designated Standards Maintenance Organization’s request, to adopt under HIPAA. There are delivery acknowledgements: The TA1, which is an interchange acknowledgement, as well as a TA3. There’s syntax response acknowledgements, there’s the 997 functional acknowledgement. Many people use that acknowledgement today; however, it just responds to the syntax, where the 999 responds to the syntax as well as it has the capability to report implementation guide errors. So that’s why we’re focusing on the 999.

Then there’s business application acknowledgements – the 824 and the 277. Now the 277 is the claim acknowledgement. You may also see it as the 277CA, and that obviously is an acknowledgement associated with the 837 transaction. So the three that are highlighted in red are the three that I’m going to focus on because that’s what was in the DSMO request. Now the other type of acknowledgement is a response type of transaction, so if I submit an eligibility request, which is a 270 transaction, provided it doesn’t fail in the delivery or syntax of implementation guide checks, I would give back a 271 as a response.

So keeping in mind the definition of acknowledgement is to give a response to work that was done, hence the response transactions could also be categorized as an acknowledgement. But our focus is not on those. Those have already been adopted under HIPAA. So I’m focusing on the TA1, the 999 and the 277.

When you look at it from a reference model point of view – and this is probably very hard to read in the back – but as a submitter of a transaction, and we look at this from a point to point because there will be a little bit of differences depending on if it goes through a clearinghouse or a switch or something. So you have a submitter that would submit an X12 transaction – and we’ll just say it’s a claim, so it’s an 837 claim. The first unit of work is to verify the interchange. So I’m going to verify the outermost envelope, the ISA and the IEA.

If it doesn’t pass then we return a TA1 response. If it does pass, then it goes to the next level, which checks for syntax as well as the implementation guide. So if I have an error there, then I would report a 999. Now a 999 could also give back a positive, “yes, everything passed.” The TA1 can do that as well, can give back a positive as well as a negative. The 999 can give back “I accepted,” “I failed,” or “I accepted with error.” From that point, then it goes into the application validation process. So it’s a claim, so I’m going to do what’s considered front end editing, to check some business rules that I don’t need to bring a claim in, into my adjudication engine, if there may be something wrong up front.

So if things pass, the 277CA gives “pass-fail” as well. And then the data is then transmitted to the, in this case, adjudication engine, and you’d have your work complete type of transaction, which would come back on an 835. So at a high level that’s kind of the flow. So as I mentioned, the TA1 is the interchange. It’s to report the status of the outermost envelope, the ISA and the IEA. It performs your basic checking of that envelope.

The submitter actually says whether I want an acknowledgement or not, unless you’ve already decided in your training partner agreements in regard to acknowledgements. So there’s a data element in that envelope that says, “I don’t want an interchange acknowledgement” or “I do want an interchange acknowledgement.” You can think of this like a FedEx. You send a FedEx and you click on that little box that says, “Yes, I want an e-mail when it was delivered.” So basically it says, “Yes, I delivered that FedEx envelope to the recipient.” It doesn’t look to see what’s inside the envelope, to know if that person really wanted that package or not. It’s just basically, “Here, I sent it, you received it.” That’s what the TA1 is.

The 999, as I mentioned earlier, is used to report syntax. So if it’s a problem with the actual structure of the X12 transaction, as well as to report implementation type of errors, such as an implementation guide may constrict the number of repetitions of a segment or it may only allow certain values in a data element. So in that regard it’s verifying the implementation guide and if there’s errors you would report that on the 999. You could also report that it’s a good transaction, so to speak, it met my requirements in regard to syntax and the implementation guide.

In addition, you can accept it with errors. Maybe the errors aren’t that critical and I want to go ahead and bring it into my system. So you can also report that. And this is reported at the transaction set. So keep in mind this is reporting at the transaction set so it’s reporting on the 837, it’s reporting on the 270. It’s not reporting on the individual claim in an 837 or an individual eligibility query. It’s reporting on the entire transaction set, so that’s something to keep in mind when you talk about the 999.

The 277CA is a claim acknowledgement type of transaction. As I mentioned earlier it’s in the preprocessing stage, so think of any type of front end editing that a health plan or a payer or a processor may do. That’s what the 277CA reports on. It’s not to replace the 835 transaction. You’re not going to go and adjudicate it and send back the 277CA. And this will report on both the – it can report on the claim level as well as the service line or detail level or both. So you can accept it, or non-accept the actual individual claim into the system. So it can report on the claim or encounter as well as the service line detail. So that’s the 277CA.

Some interesting facts about acknowledgements. One that’s not on here is the acknowledgement actually has its own version. A lot of people don’t realize that your outermost enveloping has its own version that’s separate from the actual transaction. Now most entities today put the 5010 in the ISA as well as have a 5010 coming in, in the transaction, or a 4010. But just something to keep in mind is the outermost envelope does have its own versioning.

Never acknowledge an acknowledgement. Don’t send a TA1 for a TA1, otherwise you’re in an endless loop of acknowledging an acknowledgement of acknowledging an acknowledgement and you’ll never get out of it. You don’t send a TA1 for a 997 or a 999 as well. The 277CA, it’s a little bit different type of transaction, so you would consider sending a TA1 and/or a 999. And then we have the work complete transactions, the 271, the 277, the 278, which is the response to a 278 as well as an 835. Now, whether you send acknowledgements – you know, the TA1 and the 999 – for those type of transactions depends upon if they’re submitted in real time or batch, which leads into the next slide, which is Real-Time Acknowledgement Recommendations.

When you talk about, when you send acknowledgements, when you don’t, when you mandate acknowledgements, when you don’t, you need to look at was the transaction sent in a real-time mode or a batch mode. It makes a difference. WEDI created a White Paper called WEDI Acknowledgement Recommendations, and these charts are from there. And they went through and developed the charts, people with X12 actually co-chaired or very actively participated in the development of these recommendations. So in a real-time environment the acknowledgements you send are going to be different than if it was sent in a batch mode. So that’s important to note when writing an IFR or an NPRM, is to note the differences between the batch and real time.

So if we look at a real time eligibility request, a 270, you wouldn’t send a TA1 unless there was a problem with the interchange envelope. Then you would send that. You would not send a 999 unless you failed it for syntax or an implementation guide error. Now the implementation guide error is a little tricky on this one because technically when you look at the 271, which is the response transaction to a 270, and you look at some of the data elements and some of the codes that are in there, you could potentially send a 271 for some implementation type of errors as well. But ultimately most people sent that 270, they’re waiting for a 271 unless there’s a problem with syntax or the interchange. So it’s very important to keep in mind whether it’s a real time or it’s a batch transaction.

Now batch transactions, as you see, they’re a little bit different. And I’ve listed each of the transaction sets, if it’s an interchange error it’s a TA1, if it’s a syntax or guide problem, it’s a 999. If it’s a pre-application validation type of thing, for a 270 you could send back a 271. You could also send back an 824 which is an application advice type of acknowledgement, however the industry hasn’t come to a consensus on that transaction so at this point we’re not asking for the 824 to be adopted under HIPAA at this point. So that’s why those items are grayed, so to speak, on this chart.

So in regard to resources there’s the X12 Acknowledgement Reference Model called the ARM. You may hear that term, the X12 ARM. And we’re not talking about an appendage, we’re talking about an Acknowledgement Request Model, or a TR2. The acknowledgement TR3’s, the 999, can be found at the X12 store, and then there is the WEDI Acknowledgements White Paper. That is also available, that I recommend people read that White Paper. It’s very good.

So I included some scenarios but due to time constraints I’m not going to walk through the scenarios today. I’m just going to kind of give a “how I put these in the slide deck.” Basically there’s a diagram, there’s actions, and underneath the diagram it talks about each action. So I pulled out a point to point batch type of transaction, in this case an 835, and walked through the flow. I also included a claim, because it’s a little bit different because you’ve got the 277CA associated with that, so again the diagram with the actions. I pulled out a real time request and response, again, so you could see the flow, the actions, and last but not least I pulled out a clearinghouse model. This is a little bit more complicated, as you can see, but I wanted the Committee to be able to see that, yes, acknowledgements do work for all the different types of flow that a transaction may go through. So there’s a couple of pages of the data flow model in regard to the actions associated with submitting via a clearinghouse.

So I’d like to thank the committee for inviting me today and I look forward to your questions. Next step is Mike Cabral with CMS.

DR. SUAREZ: Thanks. We’ll go to Michael. Is Michael on the phone?

MS. BUENNING: No, he has just submitted written testimony.

DR. SUAREZ: Oh, he just submitted written testimony which we received already here. So I think we’re going to go to Lisa, but let the record show, I guess, that we did receive the testimony from CMS on the acknowledgement spending. Lisa?

MS. MILLER: Very good. I’m still Lisa Miller, how’s that? And I’m not going to talk about X12 since Margaret already did that for us. I’d much rather get on to the next slide. I am the Chair of X12C, which is the Communications and Control Subcommittee. We’re a little bit different in the fact that we serve all industry in X12. Our Committee focuses on the application control structures, the control and management transaction sets, EDI architecture, and other technical issues as they relate to the standards and their processes. We do control and management transaction sets and that’s where acknowledgements fall.

One of our other duties is for the most part we also do the requests for interpretations on the standards, which means I write a whole lot of the time. When you look at these – Margaret’s already gone over what those transactions are. Again, the ones that are highlighted in red are the ones we’re recommending. But I do want to talk a little bit about these. These are the transactions that live within X12C. We work very closely with all other industries, including healthcare, to help meet their needs in how they use these control standards, that these have been in place from the very inception of X12 and utilizing X12 EDI. And it’s foundational to the integrity of an EDI implementation regardless of when in history you are. So when we talk about a TA1, we talk about a 997, we talk about some of these other transactions, and I have some further in here for you – they are used whether you’re FedEx, you’re UPS, you’re Wal-Mart, these are used and are considered foundational.

The business application acknowledgements are a little bit different and they’re not considered part of the base ASC X12 control transactions and segments. They were created for a specific business. For example, you would not use the 277 claims acknowledgement for something other than an 837. That transaction was written specifically for a business need, so when you look at that 270, 271 pairing, you wouldn’t see the 277 claims acknowledgement used for that. And our response transactions can also fulfill the role of an acknowledgement at a business level. I really want you to think about that eligibility, that 270. You really expect that response and you want the response to be the 271. There are AAA segments that actually can give you errors. We don’t want in those paired transactions, especially in real time, to see a TA1 or a 999. In fact, I’m going to apologize to Margaret, in real time the TA1 is not recommended with open communications, meaning I’m holding a port open, because if you drop that open communication you have no place to send that TA1. It’s not like a batched environment. So that’s a very key point for you to understand. And yes, I am trying to keep this in plain English so if I fail you can stop me.

Moving on to X12, we also own a bunch of other documents that are very important for you to know about because these are our founding documents that tell us when and how and what these things do. The first one is X12.5. It is a standard document. It is the interchange control structures. The next one in line is X12.56, which is the interconnect mailbag control structures, and X12.6, application control structure. We also are the author of the acknowledgement reference model. We have one other one that is key and critical in this, is compliance in X12, because that tells you what as you’re going through and you’re acknowledging to go back and say does this conform and is this in compliance. So that document ties all of these things together. These documents provide the rules for ASC X12 EDI. They are often referenced when we do a formal request for interpretation. If you look at any of those – they’re public on the X12 website – you will see that we go back and we reference those foundational documents and tell you why you can do something or you can’t do something, or what the interpretation is.

We have numerous RFI’s regarding acknowledgements. I went out and counted. We have over 45. And just so you know, right at the moment I have 49 that are sitting within my Subcommittee to be responded to. So we are active in conjunction with X12N, to answer these questions that come in around acknowledgements, and they can be found at X12.4.

So I’m going to talk a little bit more about things. So I want you to imagine about Shrek and Donkey. I happen to have six kids so I always put things into real language. So if you had Shrek and Donkey talking, you would have somebody starting like this. And this is Shrek: “For your information, there’s a lot more to EDI than you think.” “An example?” “Example, eh? EDI is like onions. They stink.” “Oh, does it make you cry?” “No, layers. Onion has layers. EDI has layers. Onions have layers. You get it? They both have layers. So when you think about EDI, think about the layers.”

I’m going to give you a slightly different picture and I hope this one sticks with you a little bit. EDI was actually created to replace paper processes. So when you think about acknowledgements, I’m going to walk you through a FedEx delivery. How many of you have had a FedEx delivery? Raise your hand. Okay. So when you get that hard FedEx envelope and you get it, what’s the first thing you do? You look at it and you say, “Did this get addressed to me or not?” What’s the next thing you do if it’s addressed to you? You open it, don’t you? What do you do with that envelope? You throw it away. If you look inside the envelope, there might be lots of little paper envelopes inside, and you look at those. And you may say, “Oh, yeah, this is really for me, but ew, this one’s not.” Then you go to the next layer. You open up that next envelope, don’t you? And what do you find inside? Pieces of paper, hopefully.

That’s basically your structure of EDI. Just like you open up those envelopes in real life. That’s what we must do with EDI as you move through the process. So if you look at your outer envelope, it’s your TA1. If you go down through to your inner envelope and into those sets which are, if you think about it, pieces of paper clipped together with a paper clip – we call those transaction sets – that is where your 999 comes into play. I can either say the entire inner envelope is gone or I can go ahead and say those transaction sets I’m rejecting, so there’s one little envelope in there that I’m saying I can’t deal with.

And then the last thing is, we’re at the specific claim where it’s a single business unit, it’s a single piece of paper. And that’s the 277CA. Now that’s about as in plain English as I can talk about acknowledgements. But as you think about the onion, you have to peel through those layers to get to the point where you know you have something good enough for business. But it’s also at those points where you know that you had receipt, that you know it was healthy enough to move forward with, and that you’re communicating very quickly with your trading partners. So again, if you don’t have any other picture in your mind, that’s a really nice, clean picture of acknowledgements, and to put them into perspective.

So I’m just going to say this. I’m going to walk through all of your questions and hopefully answer them for you. One of your questions is, which transactions required acknowledgements. My answer to you is, “All transactions require acknowledgements except for acknowledgements.” We don’t do the infinite loop. If you’re exchanging AXCX12 EDI without the implementation of X12 acknowledgements, there are many issues with receiving the format, the content, the integrity of the change, the functional group or sets within the groups from the sender, and the following may occur. You end up with things like proprietary acknowledgements, so if you’re not going to use ours you’re going to make something up to your trading partners. You’re never going to know something was sent. You have your black hole syndrome. The exchange is no longer electronic. We just went out of EDI, and now we’re sitting in phone calls, faxes, human to human conversation that could have been handled had we implemented correctly, and quite frankly the cost of business goes up. Pretty simple statements.

All transactions require acknowledgements. For real time or for paired transactions, like an eligibility request and response, if the expected transactions or an ASC X12 acknowledgement transaction is not used, then you’re never going to get a response. And the things that will happen is, in the case of a real time system you’re going to lose faith and confidence in that real time transaction. You’re holding open that queue. Nothing ever comes back. And what happens is, you stop using that service because it doesn’t work. So we’re actually undermining what could possibly be done.

Benefits of acknowledgement. I can’t say it enough. No black holes. Now I am going to put a little caveat there. When you’re talking about a sender to a receiver. Margaret showed you that lovely picture of the clearinghouse. And that got pretty complicated, and we can talk about that in just a few minutes. But when I’m sending from a sender to a receiver, if you use acknowledgements, the TA1, the 999 and for the 837, the 277, no black holes. You should account for everything that goes in and be able to communicate back to your provider, your trading partner, what came out. Immediate response. There is no reason not to do the TA1 and the 999 immediately and get that back, especially that TA1. Think about your FedEx envelope. You had it, you opened it or you saw it, and it wasn’t to you. What would you have done? Handed it right back. Same for acknowledgements. Reject those issues right away, so that that trading partner can make the correction and get their data in. And that becomes really important when you’re starting to talk about adjudication and check runs and all of those things.

Electronic accountability for the sending and receiving of X12. This is your audit trail. There is no excuse for not knowing exactly what comes in and out. Removal of proprietary reports. Can you imagine if you had 650 trading partners and each one sent you a proprietary report? Well I can imagine, because that is our climate today. The ability to utilize other acknowledgement transactions. We don’t just have those three acknowledgements in X12. We have many, many more that have been done and that are there for our use. So as we mature and people are more accustomed to using acknowledgements, we can start expanding that, or even creating new ones.

Common content from any or all trading partners. You’ll get the same things. There’s only so many combinations of the codes that can be used, but to get the same common content. Reduction of staff time and support. Remember, if you fall out of that EDI and you’re back into the paper world or back into the phone, your staff time goes up exponentially. Alert of issues. It’s immediate on both sides of the transmission. And I can’t say it enough – end of proprietary reports.

Specifically for claims, the TA1, the 999 and the 277CA become very, very important because it’s undisputed as when that claim or that interchange entered into the organization. You have a time stamp, and that becomes very important for clean claim legislation, for interest penalties, for all of those things. You have your accounting. It provides what was sent and what was received. And it decreases the number of calls into the operations center.

I do have a quote. As X12 was preparing for our testimony, we had a call with several of our staff and members, and this was a direct quote. “Without acknowledgements, providers basically waited 30 days to see if they got paid and then called on the phone if there was no payment.” Can you imagine?

So acknowledgements implementation and consistency. You asked why didn’t it happen. So I’m going to talk a little bit about 4010. Number one, not mandated, in big, bold letters. Many implemented 4010 by wrapping, hacking and mapping, keeping the responses unchanged and only slightly modified. So what they did is, they looked at it as, oh this is a format, it’s not content, it’s not a business change, and they just modified whatever they had to and they kept all of their reports that they were sending back for whatever they were getting the same. Most of the vendors during the 4010 implementation didn’t know about the TA1 during early 4010. In fact, it was one of my questions that I would ask for clients, for vendors: “Do you know what the TA1 is?” and if they didn’t, they failed and we moved onto another vendor.

Then we had the 997 sitting in the back of the IG’s as an appendix. And the industry didn’t know about those control standards – 12.5, 12.6, or even 12.56. So it was a black hole. They looked at it and they said, “Oh, this is how we implement.” Then we went on. People did use the 997, but then vendors decided that as we’re responding to implementation guides they were going to modify or enhance to meet the requirements of responding to an IG rather than to a standard transaction. I’m going to give you an example. Element data – data element number 98. Now it sounds like it might be technical, but I promise I won’t.

When you have an implementation guide, at a data element we can constrain a list of codes. If you look at data element number 98, it has over 425 codes. But when I look at one particular use of it and it’s the billing provider, there’s only one code that’s allowed to come through. 997 says, as long as it’s in the standard it’s okay, it conforms to the standard so it can go through. When we enhanced the 997, what we did is, we said, “No, it can only be a 98.” So we actually didn’t do the right thing.

And then the third thing that was going on is, our practice management systems didn’t have the capabilities to consume the TA1, the 997, and with all the different flavors and variations of these enhanced 997’s, it created a broader barrier for those practice management vendors.

And then we had the other thing that was going on. Providers’ staff used to – they were very accustomed to those proprietary reports and they were told EDI is too difficult to understand. In my day I actually had a little program for a 997. It gave them a smiley face, a frowny face, or one that was just straight across and that’s how the providers figured out what was wrong with the 997. IN 4010 the 999 didn’t exist. That was actually created in a later standard, so just an explanation of why we started out with the 997 rather than the 999.

I want to talk about the 277CA a little bit differently. This really has a lot of adoption, but it still wasn’t mandated. Payers look at it as a cost to implement, and in the discussions with X12 members here were some of the comments. There was an ROI that was a challenge for the 277. It was replacing those proprietary formats. Many of them still had both the proprietary format and to do the 277CA.

It required business processing, re-sequencing and coding, and from a content perspective many of them went from one big mondo report that providers may have to wait a long time for, to one that was three. So it seemed more complicated to peel that onion, and the nicer part with the three is that they would have had a shorter response time and be able to correct things more quickly.

So you ask another question – and I’m going to use a quote. I happen to be a big Mozart fan. There’s this really fabulous quote from Emperor Joseph II. He was talking about Salieri after he did one of his – it’s the opera with Papageno, and his message was, “Your work is ingenious. It’s quality work, and there are just simply too many notes, that’s all. Just cut a few and it will be perfect.” Mozart’s response was, “Well, which few do you have in mind, Majesty?” So when you ask me the question, “What acknowledgements are needed?” I would ask you, “Which one of my notes do you want me to cut, because I need all of them to peel my onion?” And those three would be: the 999 for claims, the 277CA, and the TA1.

So I’m going to go through our barriers to acknowledgements. Number 1, not mandated. You hear it over and over. I must have gotten in the last – as Chair of X12C – in the last two months, I must have gotten about 45 e-mails asking people, asking me to tell them is this mandated or not. And of course I can’t say that. We can say “recommended,” we can point to the people using it. But because they aren’t mandated, it’s, “Well, I don’t have to do it.” There is a cost to implement.

The ROI challenge. Everybody wants to hold onto the stuff they’re used to. They don’t want to move to something that they don’t understand. And then we have that enhanced 997 hanging around, which people have programmed for and they don’t necessarily want to replace, and we’re hearing that they have to support not just the proprietary format but that enhanced 997 and now the TA1, 999 and the 277. And by the way, there was another 277. You’ll hear, it was called the 277FE, or Front End Edit. That no longer – well, it does exist, but it’s no longer what we recommend. It is the claims acknowledgement.

It will require business processing re-sequencing, but it’s a good thing, moving more and more of those edits forward to clean up the information coming into our adjudication systems will help us with more accurate quality data for reporting. And we all know as we move forward that we need better and better data because we have more and more requirements with legislation around quality measures and reporting.

Content – again, I can’t say it enough. If you went from one report and now you think you have three, why do I need three? Why do I have to deal with three? Well you need three because you’ve got to peel that onion. There’s no way around it.

I will also make one comment. The reason for the 824 and why that one does not work well as becoming the single acknowledgement – and that was bantered around – is because when EDI comes in and you go through that envelope process, and I actually was going to bring you envelopes to play a game but I decided I didn’t have enough time, the 824 responds back to the original FedEx envelope. Can you imagine through your business applications having to take that FedEx envelope information all the way through to adjudication, and then hold everything to answer back on that one submission?

And then when you think about the clearinghouses getting involved in the middle of this, where it’s gone from hop to hop to hop and you’ve opened up those envelopes, how you would retain that to know what batch, especially if I’m sending to a clearing house and they decombine and recombine. That becomes a nightmare. So the 824, if it’s used, that it’s the only thing and it carries all of that information through, becomes unimplementable.

Okay, so existing standards. Here is a nice list for you. I’ve talked about them earlier, but I really want to focus in on that acknowledgement reference model. That’s been around since 1999. We just updated it in 2009. It really gives you the operating type information on how to implement acknowledgements. And now we have a section, Section 8, which is specific to industries, where they give specific industry guidance on what we’re expecting as far as acknowledgements. This is key and foundational, not just one industry but to all of our industries as we move forward.

To give you some other examples of acknowledgements within X12, I gave you a nice, long list here. I don’t have to go through all of them. I do want, though, to point out the TA1 and the TA3 are unique that they are segments. They are not transactions like a 999, or like a 993 which is a secured receipt or acknowledgement. These are ones that are carried within its own little FedEx envelope. It would be like getting a return receipt. Think of it that way, very simply put.

Okay, preconditions and requirements. So Margaret touched on the versioning. There is no reason a 4010 transaction may not be acknowledged by a 5010 acknowledgement. So I could you a 999 to respond to a 4010 claim. No reason I couldn’t. And that’s why control segments are great. Now there are a couple caveats when you’re talking about control segments like the outer envelope. You must make sure that when we hit – we have now a repeating element within X12 that you must use the interchange envelope, the FedEx envelope that allows you to have that repeating element delimiter. That’s a very key one.

But can you imagine how confusing it would be to tell some of our practice management vendors that they’re going to get one kind of envelope, that what’s going to be inside is different? So our recommendation is that for 5010 we use the 999, we use our 5010 envelopes, and that we move forward cohesively. But around those control segments, if we had an issue where we needed to add a code or codes to the outer envelope because you want different business functionality, it would be possible to use, say, a 6020, a 7010 envelope with a 5010 transaction to get that functionality.

So preconditions. It’s real simple. Are you sending X12 EDI? If your answer is “yes,” then from sender to receiver you need to have an interchange acknowledgement and you need to have an implementation acknowledgement. Otherwise, you’re not going to be able to tell people when you got it, and two, that you had it.

Now I do want to make a note. In the interchange acknowledgement, this one is unique that it is the only acknowledgement that is sent at the request of the sender. The sender controls this. If it is a zero, it will not be sent. If it is one, our 12.5 says it must be sent. And there is a request for interpretation from X12 that documents that fact. So if you’re interested I can certainly provide you with a copy.

Today’s practices. Some transactions appear not to require acknowledgements in today’s environment. So I’m going to give you my example, which is the 835 healthcare claim payment advice. For some reason we think that that one doesn’t need any acknowledgement, so you sent it off from the payer to the provider. And providers don’t do acknowledgements. They don’t send back and say, “Hey, I got it.” And they don’t send back and say, “And I couldn’t use it because it had problems.” What happens is, they get on the phone, or they bring it in, and they try to post but there is this perception that some transactions are excluded, and that is just not true. All trading partners need to utilize at least the TA1 and the 999. There are no exclusions.

So priority areas for operating rules. Immediate adoption of the TA1, 999 and the 277CA, in agreement and per the X12 Acknowledgement Reference Model and the ASC X12N Technical Report Type 3 documents for the 999, 277, and TA1. The ASC X12 Control Standards must be adhered to by any operating rule, and if there are questions the request for formal interpretation process should be utilized as it is today across other industries.

A clear and defined process must exist between operating rule entity and the SDO. For example, current proposed operating rules do not include the TA1. This is the first line of defense and must be included. It is the first time that someone can say, “You got it or you didn’t.” Otherwise, we end up in that black hole scenario. IT must be implemented per the standard and the ASC X12 guidance in the 999 TR3 and per the ASC X12 RFI. The 999 must be adopted for 5010 implementations.

We’ve had numerous RFI’s concerning the 999 which provide consistent implementation guidance. One of them went through each one of the codes and said when to apply it and when not to apply it. And again, that is freely available from the X12 website.

In the case of X12 and other industries, we have more than one industry, more than healthcare, that utilizes our acknowledgement transactions. I listed some of them earlier. Your Fortune 500 companies that do EDI all use TA1’s. They all use 997’s. Those are foundational to our industry. So, if we have a request for a change, it may affect our other industries as well, and that includes government. Government’s one of our biggest users.

Existing operating rule types such as those found within the technical type reports – I’m going to give you two examples. We have the Acknowledgement Reference Model. Again, I’m going to say it, it’s been here since 1999, updated in 2009. And the current Electronic Funds Remittance and Electronic Funds Transfer Transactions need to either be referenced, or incorporated into operating rules.

So in summary, ASC X12 has a rich and robust acknowledgement process which has served other industries supporting the very fabric of the U.S. economy. The same acknowledgement model needs to be implemented by the healthcare industry, and it is time to put an end to the black hole. Thank you very much.

DR. SUAREZ: Thank you very much, Lisa. We’re going to go to – I think you’re going to be presenting on behalf of CORE? Okay.

MS. GABEL: Annette Gabel, and I’m presenting on behalf of NCPDP. NCPDP is an ANSI-accredited standards development organization. I’m not going to go through all of these bullets, but the important one that I want to focus on is that we represent the pharmacy industry, and we focus on pharmacy services, and we have the highest member representation from the pharmacy services sector of healthcare. And when I say that it means that it’s not just the providers, it’s the vendors, and it is the processors and the payers in the health plans. So we have a vast representation from those companies that are involved in the pharmacy service division of healthcare.

So I know Margaret touched on this earlier but we just wanted to go through. So the request for acknowledgements had been submitted to DSMO and they came back with a recommendation. And they basically said that they would approve the request for the acknowledgement transaction; however, they recommended further public comments as it related to the 835 and the 820 acknowledgements. They said that currently they recommend the acknowledgement files for the 835 and the 820, but they should be based upon trading partner agreements. So NCPDP feels that if a regulation were to name acknowledgements, it must support the DSMO recommendation that it should name acknowledgements as a HIPAA-named exchange and they should receive industry input on the 835 and the 820 acknowledgements.

Operating rules for the 999 acknowledgement would need to be developed, if they aren’t already contained in the guide and/or developed by X12. So I wanted to speak a little bit about acknowledgement transactions that already exist for NCPDP. So we have HIPAA-named transaction standards, we have the Telecommunications Standard Implementation Guide Version D.0, which is our claim billing transaction, and today that requires a response to the claims. So that already contains an acknowledgement. The same situation exists for the Batch Standard Implementation Guide, which is basically the claim billing in a batch format that also requires a response go back to the provider that we use as an acknowledgement.

We have the Medicaid Subrogation Standard Version 3.0 that was just adopted and is required as a HIPAA transaction standard as of 1/1/2012. Again, that is a transaction that requires a response. So as you can see all of the above standards have response message files that today serve as acknowledgements for NCPDP.

On the other side, the HIPAA transactions that are today used by the pharmacy industry from the X12 environment, we use the X12 270/271 for e-prescribing, so this is from the physician inquiring on eligibility. It does contain some additional information. Today it’s used as a real time response. The X12 271 is used as the acknowledgement when the 270 is sent. The X12 834, again, is used for providing eligibility information on cardholders and their dependents, and the transaction coming in today is responded back to the entity submitting with proprietary formats. So what’s important for the entity submitting the 834 is not so much that the processor or the health plan that’s sending it knows that the transaction was received, they’re more concerned about what was done with the information in the 834.

So when the pharmacy industry, since we’re doing real time transactions, if that 834 is received that’s great, but if the information isn’t applied in a real time environment, then the individuals that they’re sending on that file today cannot go to the pharmacy and get their prescriptions. So it’s not as important, although it is important that they know that they received the file, they really need to understand, was the file accepted, is the person now eligible, how many records did you receive, what did you do with those records, did you terminate anyone.

They need that type of information, so today there are proprietary formats that go back to the submitting entities to tell them how the transaction was used. So as a result in X12, they’re developing a response file to the 834, which will act as an acknowledgement and will contain that detailed information.

For the X12 835, which the pharmacy industry is using today to provide pharmacy remittance information, when we submitted our comments to – when NCPDP submitted their comments to DSO we did not require an acknowledgement for the 835. And the pharmacy industry, the response to the 835 is not as important because of the fact that we have the real time claim transaction where the pharmacy is getting the information, so they know how they’re going to be paid on the transaction. They’re getting a response to that submitted bill.

When the 835 comes it’s really just the information that they need to receive so they know how to apply the payment. But they basically receive the information already on the real time response that tells them how they’re going to get paid. So today the pharmacy industry does not use acknowledgements for the 835.

I think I went ahead of myself here. So as I was just saying, when we submitted our response we did not recommend or request that an acknowledgement be sent for the 835. We didn’t see a value added in requiring the acknowledgement transaction, and the cost of implementing the transaction had no return on investment as the current process of reporting issues through an 835 help desk works today for providers and payers. So this isn’t just a – this wasn’t just a submission from one side of the industry. As I said, NCPDP represents all parts of the pharmacy sector. So when we put our response together this was input that we received from both the provider and the payer side. So both entities did not see the need to have an acknowledgement for the 835.

And again, as far as the benefit requiring an acknowledgement on any of the X12 transactions that we currently use, as I said earlier, the only benefit to be obtained is to create a response feedback file for the 834. Again, we need much more detail on how the 834 was processed. It’s not just about receiving an acknowledgement that the transaction was received. We really need to know how that transaction was applied to the eligibility system. And hopefully the 834 workgroup at X12 will continue that process so that we can remove some of the proprietary file formats that we all use today. And that is basically it. I’ll be happy to answer any questions that you have.

DR. SUAREZ: Thanks so much, Annette. So we have Gwen, I think, who is going to present.

MS. LOHSE: Thank you for inviting us here today. These guys have done such a good job I don’t think I need to go into a whole lot of the details. So just as a quick overview for what our testimony submitted – and we did not go into a technical level detail because we knew that they were going to do a very good job with the technical level and we have been supporting acknowledgements through the CORE operating rules since 2005. I think they did a fantastic job with the overview, so again, I’m going to keep it pretty short as to what to go over.

You’ll see in our detailed testimony there’s a few key themes. One is, there’s a long-standing business case. And again, I don’t want to repeat – you guys have a very long day and I think Lisa did a fantastic job about the black hole and why it’s needed and the purpose of it, and also across each of the acknowledgements. So there is that longstanding business case. And we’ve done a lot of analysis with that, within the operating rules group. There’s been detailed analysis about what’s happening in the market, what’s not happening in the market, and why, and I think you’ll hear later today from some of the state efforts, they found the same things. So you’re going to see themes about why are these used and where are they needed.

Additionally, with the standing business case, there’s real time and batch. I think again you’ll hear today the acknowledgements are for both the real time and the batch, and for different reasons. We do not want to flood the system with acknowledgements that we may or may not need, because they cost money. Every time we send something in some of the instances they cost money, so how do we make sure? With real time, if we don’t need it because a transaction comes back immediately, we don’t use it, and with batch we do have it.

And then barriers to adoption. Again, I don’t want to repeat because, again, I think they did a fantastic job on that. So as we think about what Lisa went over with the barriers and the technical, we’re very much aligned with that. And I think also Annette talked a little bit about, for instance, when acknowledgement isn’t used at the end, at the 835, there’s some instances again where the acknowledgement is not necessary so an analysis needs to occur about when it is necessary because otherwise you start sending so many acknowledgements that you reduce the business case. And we do not want to do that, obviously. We want to be using these and using them per the standard, per the implementation guide, but understanding that there’s a cost when they come out and someone’s receiving them at the other end along with the rest of the information.

So as we think about the themes, again, I’m not going to go over the business case – we do believe that adoption of acknowledgement should be national and done in a phased transaction-specific approach. And that, again, goes through what is the business case with each of the transactions for using them in real time and in batch, because you have to study that, look at it, see what’s feasible for market maturity, and what people are ready to take in. The industry can only do so much at so much time, and that goes for the providers, the venders, the clearinghouses, the health plans and now the HIE’s as they get involved.

So as we think about the business case going through the transactions, and again, that supports the TR3’s and the implementation guides and the standards, so supporting the standards and the implementation guides in a phased national approach, and insuring that we’re really focusing on the business workflow of the provider and what value is it going to bring to them. We want, again, to be business driven and not technically driven because there is cost associated with it.

Additionally, I think we already know this – and again, they all did a fantastic job before me about the difference between the standards and the operating rules – both are needed. The operating rules for the last five years have been driving the use of the acknowledgements in a consistent way, following the standards, using the guides. They need to get adopted, and the business case is clear. They’ve gone over it. It’s important that we start figuring out as an industry how we are going to adopt these, and then studying the benefit of it and tracking it.

Additionally, as we think about infrastructure and communication interoperability across sectors, and then now across industries because we have with the EFT and the ERA the financial services industry, we need to think about how do the acknowledgements flow across the sectors. Because once you start having interoperable systems you’re going to be seeing clinical and admin move together and then you’re going to be seeing the healthcare services and the financial services work together.

So as you can see – and I think again, Lisa did a fantastic job highlighting what the role of the clearinghouses are and the hops in the middle, we’re going to really need to think through how do the acknowledgements hop across the different sectors. It’s going to be an important piece, and I think we’ll see that more and more with the EFT and the ERA, and more and more as clinical and admin come in again.

On-line certification and testing – as you all know, and it’s detailed in our written testimony, the CORE operating rules, when they started – again, CORE was started in 2005; from the beginning there was a commitment to use acknowledgements. There was also a commitment to test for them and do certification testing. And that has been extremely valuable for different trading partners, and I think you’ll hear from some of the people that are certified later today. As they go through certification and testing, especially health plans that are working and relying upon their vendors to send the acknowledgements or providers that are relying on their vendors, we’re really finding out what the complementary roles are in the acknowledgments. And that goes back to the hop. And right now the hops are not well-defined and so you cannot say in every particular instance the acknowledgement is going to be used by the same type of stakeholder in the same way.

We need to work together, and I think the certification and testing really helped with that, to define how do the hops work and how do they move across the system. There’s many systems, many entities and providers that use different systems for different transactions, so you’ll have a provider that will use one system for eligibility, another system for ERA, maybe a different system for claims status. We’re seeing a reduction in that, but it’s still there that you have these different systems. So as we think about acknowledgements, it’s got to be – we have to look at it at a transaction-specific basis and think about in the provider’s office what tools are they using and therefore how do the acknowledgements apply to that. And then, if they’re using different tools it may be that we really need to reach out to the vendor in the clearinghouse community more to figure out how are the acknowledgements going to be used across these transactions, and that’s one thing the operating rules have really focused on, is the flow from the provider through whatever vendor systems, and in many instances it could be multiple hops and then it doesn’t work if all the hops aren’t involved, and out to the health plan, or the opposite way.

So that certification and testing is really essential to study the process and also for the trading partners, when they say they’re using the acknowledgements testing with their trading partners to make sure you’re really having the acknowledgements go through like you initially had planned.

This is kind of an overview. And I think, again, Lisa did a great job showing the different envelopes and how the process works together so I do not want to give a long day, I don’t want to repeat anything that you may have already heard, but this is to highlight – and it’s again in the written testimony – that we have different payloads right in the top diagram in the middle, different payloads. They may be the X12 transactions, they may be zip files, they may be personal health records. And then we have the envelope, and that right now could be a mix of different types of standards that flow the envelope through, and then metadata to push that through, and then in many instances the public internet or proprietary weak pieces.

I’m sure you’ll hear from some of the implementers later today but it’s important for us to think about acknowledgements are essential, they fill a business case, and they need to follow the standards and the implementation guys. But as we think about interoperability we’re going to have to take into account that these acknowledgements are flowing over these various different layers. So it’s not only the transaction-specific issues with the vendors and the clearinghouses, but then it’s the interoperability of using the different layers to send the data. So we want to be really studying this, looking at it with each of the transactions in a phased approach to see what makes sense.

This is a high level overview – and you can probably see it in your written testimony a little bit better – about what the core rules to date have done for acknowledgements. And it’s a summary of both the phase I and II rules, updated for V5010, and then also the draft phase III rules. And I’m just going to point out a few things here. You’ll see the transactions in the second column – eligibility claim status, healthcare claim, prior auth, remittance. And then the payload pieces.

And you’ll see the middle column is the real time acknowledgements, and then the last column is the batch. And the batch and the real time are not always the same, because again, based on the business case and based on the fact that you don’t want to overload the system with too many acknowledgements, they’re not always used in every instance. And that may change and it may evolve but right now within the CORE operating rules based on research that has been done to date this is what was agreed upon, this is what is tested for, and this has been implemented.

You’ll also highlight here – and I think Lisa did a great job with this as well – when CORE originally started we supported the 997. And again, I’m not going to go into any of the technical details since you already heard them. As 5010 came out, and again the first CORE rules were written, started written in 2005, 2006, the testing started so it was based on 4010. When that came out we did have pushback to say because they’re non-mandated standards that let’s not move to the 999. After a lot of analysis there was support to go to the 999, so you’ll see in this, it’s with the V5010 updated, the 999, at the time that that analysis was going through, the TA1 was going through edits so it was not included in the V5010 update because the operating rules can only support standards and implementation guides. They’re not writing the standards, they’re building upon and supporting existing standards and their implementation guides, so it’s not included.

So again, you’ll also see the 277CA. There was a huge push – and I’m hoping you’re going to hear from Noam Nahary today from Montefiore Medical Center. He actually chaired that group. He’s obviously in a provider’s office and he did a fantastic job to really highlight what the 277CA and the value it can bring to the providers. And there was a business case driven analysis. We can send you the business case. It’s pretty long and I know you have a lot of documents, but we’re happy to send that to you and I think you can ask Noam some excellent questions. And I believe you’ll hear from some other folks today too, that really looked at that. So the 999 and the 277CA, there’s been tremendous support to use them, to get them involved in the certification and testing, and I think you’ll see that is happening in the states too. And if you’d like any of the copies of the rules, the actual written testimony has links to the rules.

I’m going to conclude with this. We obviously have a moment right now to have an opportunity to adopt the acknowledgements, and we shouldn’t miss the opportunity because it may be quite another long time until we have another opportunity to have a national approach to these critical standards, and they really do as Lisa went over fill in the black hole and add a lot of value to the provider. And that’s the whole reason we’re here – reduce the costs, get to administrative simplification. And the Healthcare Reform Bill in section 1104 provides the ability for the operating rules to build business rules to support the HIPAA transactions. And in order to have business rules and focus on the business piece, the acknowledgements are needed.

And that’s my conclusion, and I hope that was helpful and kept it short enough, given everything else that you heard before.

DR. SUAREZ: Thank you, thank you very much. And perfect timing to go into some questions from the Committee members. Before that I think we had some additional Committee members that joined, so if they want to introduce themselves, so Mike and Jim?

DR. SORACE: I’m Jim Sorace from ASPE.

DR. FITZMAURICE: Michael Fitzmaurice, Agency for Healthcare Research and Quality.

DR. SUAREZ: Did anybody else join on the phone from a Committee member? Okay, let’s start with some questions. Judy?

Agenda Item: Questions by the Subcommittee

DR. WARREN: So I had a couple. One was just clarifying. Gwen, you had mentioned in there that sometimes we should use acknowledgements and sometimes not, and yet what we heard from X12 is, put them into place, use them all the time. That way there’s no decision-making that has to be made: Should I get one or should I not? So can you clarify more – it seems to me it would be more expensive to implement a sometime rule than it would do it all the time for each layer.

MS. LOHSE: It’s a great question and I think you’ll hear from the panelists today, too, and I think they’ll shed some light on this as well. Within the CORE operating rules processes the business cases were developed during 2005, 2006, ‘07, ‘08, ‘09, 10, and the certification and testing, there were instances where the implementers, both the health plans and the providers – so this is not just one of the stakeholders on each of the sides – felt that you could have acknowledgement overload. And it puts it in a very non-technical term. So in some of the instances, for example, in real time if we’re defining real time right now within the CORE operating rules, it’s 20 seconds or less. And that obviously is going to have to improve and get up to where many other industries are where it’s two seconds or less. Do you need to have both the actual transaction come through as well as an acknowledgement that it went through? So that’s a good example of why it may not be needed.

I think another example is within the 835. Annette talked a little bit about this. There may be a market maturity issue here, and that means once you’re responding in real time to the claim, you’re basically doing real time claims adjudication and the system is not yet at a point where it has the ability to do all of that. So it’s a matter of how much can we adopt, how much can we afford, and is it going to add the value. So there’s absolutely support for the acknowledgements, but the industry is changing very quickly. And so there was a support to within each of the transactions study and make sure that there is going to be a business case and a cost benefit to sending each of these acknowledgements. Because in many instances there’s charges for them.

DR. WARREN: So one of the questions I have, as we heard from X12, is that when people don’t get acknowledgements there are faxes and telephone calls which are more expensive than an electronic receipt of something that you can write a rule and have it shoved off in a bin somewhere. So I know, Lisa, you’re wanting to jump the bit here.

MS. MILLER: Yes, I do. But let’s jump back a minute about acknowledgements. There can be acknowledgement overload. So if you’re sending acknowledgements every time something is accepted, that can create acknowledgement overload. And trading partners can say, only send them to me if there’s a problem. The issue – and I’m going to correct something Gwen said – we never made any changes to the TA1. Actually where the request came in to help with the TA1 was at our ISA, which is the outer envelope. Remember that that TA1 is requested by the sender. And right now it’s either a zero or a one. There isn’t “only send it to me if there’s something wrong.”

So what we have currently in 5010 is, as the sender I can decide whether I want it or not and I can say “no, don’t send it to me, don’t get the overload.” But this concept of we don’t have to implement them I think is misleading because you do need them for the error situations. So this thought of too many notes – and I hate to keep going back to that – there aren’t too many notes. If you have a failure even for an 835 at a TA1 level or a 999 level, you don’t have anything to move forward that you would even make a phone call about because it’s a catastrophic error. The data didn’t make it. EDI is pattern based. If I can’t get that pattern into my system, then I have an error I have to communicate.

So there are two different levels, and I tried to display that to you, that I’ve got that very structural level that says is this in a good enough format that I can bring in, versus is this content I can actually use. And there’s a very distinct dividing line. But to be able to say acknowledgement overload – and we don’t need to implement them. The fact is, they must be there to communicate an error; otherwise, I wouldn’t even know how you’d start with the TA1. I think when panelists come up, it’s not that they don’t use them, it’s that we don’t want verbosity where it’s not needed.

Margaret showed you that interaction diagram, and if you read it carefully you don’t necessarily have to send one if it’s acknowledged, as long as you get one back. There always must be one acknowledgement, and it goes back to her definition of an acknowledgement for an action or something done. But it doesn’t mean that you don’t implement the TA1, it may mean I send it to you when I have an error.

The change that X12 has made to the ISA actually is adding codes that let you have a zero, one, two or three, and send it to me when there are only errors, send it to me when they’re accepted with errors or errors, send it to me, don’t send it to me if it’s accepted, I don’t want to know about those. So we have done that modification that came in as a result of an RFI. But again, that’s in 6020, it’s not in 5010. So I hope that helps a little bit, because I don’t want to see us walk away from the table not understanding that it’s not, you can’t just say it’s too many notes. They have to be implemented but we can give guidance that if it’s accepted and trading partners say, “Hey, there’s nothing wrong,” just send me the one that tells me it’s okay. I may for a claim go all the way through to the 277 and never see a TA1 or a 999. That’s an okay thing.

DR. SUAREZ: Thanks, you had another question?

DR. WARREN: Well, I just had one. Does anybody else have one?

MS. WEIKER: Can I clarify something else as well? X12, in the charts I provided about real time and batch in my presentation, keep in mind we’re not advocating in a real time environment that you send back a TA1 and a 999 and then the 271. It all depends if there’s an error up front. If there’s not, then you send back the appropriate “work complete” transaction, 271. So we’re not advocating that, and I believe that was stated earlier.

DR. WARREN: So the other piece I had was again, the comment that I think Gwen made of implementing acknowledgements by transaction, so looking at a phased in approach. So I’m just wondering, from an X12 perspective do you agree a phased in approach or just all the transactions at the same time?

MS. WEIKER: Well, my perspective is you wouldn’t pick and choose by which transaction to implement an acknowledgement. If you’re going to make a check of an envelope, why would you not check every envelope? Why would you only say, “Oh wait, this is an envelope…”

DR. WARREN: I just wanted to hear you say that.

MS. WEIKER: Yes, okay.

DR. WARREN: Total agreement.

MR. FITZ: I too love the sound of your voice. In fact, I love the sound of all of your voices, particularly when you help me know more than I did before. So I’m thinking who benefits most from acknowledgements? Probably the provider, maybe the provider’s billing service, because you send something out, you’d like to know it was received, you’d like to know was it complete enough for you to act on or is there a shortfall and you send it back and, at least I know it but there’s probably a response that’s not a transaction, that’s not an acknowledgement that says “It’s not complete and here’s what you’re lacking.”

The acknowledgement may or may not contain additional information. I think Gwen said that if you send it in and two seconds later you get the answer to your question, do you really need an acknowledgement? Do you have to chop down more electronic trees in order to get that acknowledgement? Or clog the system I think was a better way to put it. That seems to make sense.

A lot of it seems to depend upon response time, upon the completeness of the transaction and the completeness of any failings coming back to the sender that says, “Here’s what you missed,” as opposed to “It was missing something but we’re not going to tell you what it is because we want to hold onto your money.” It avoids the black hole because at least you know somebody is at the other end of the phone, or at the other end of the line or at the other end of the wireless saying, “Yes, I got something from you.”

Gwen said there is a charge for the transaction. Some people may charge a nickel, a dime, a quarter for just the acknowledgement coming back. I know one could say, “Is that fair?” But also this is a competitive market enterprise and things have costs and if you don’t want an acknowledgement then should you have the choice of whether to receive it or not. X12 says, “Yes, you should have the choice. You’ve got a zero or a one. You don’t have to get the acknowledgement back if you don’t want it, but all transactions,” X12 says, “should have an acknowledgement.” NCPDP says, “I think we’ve got a handle. We don’t need an acknowledgement in that sense. And I think Gwen is saying it depends upon the operating rules, it depends upon what is best for the system, and you need to let the system mature to find out what it thinks is best for itself. How am I doing so far, okay?

MS. LOHSE: I think that last point was extremely important.

MR. FITZ: All right. So then the question comes to NCVHS, what should we do about the current state of affairs? Should we approve? Should we push for a standardized acknowledgement that everybody has to follow, with exceptions maybe for pharmacy versus non-pharmacy. Is there advice that you would give us as to what action you want us to take? Now, from X12 it says acknowledgement for every transaction, but the center has the choice of whether it wants to receive it or not. NCPDP says we’ve got a handle, we don’t need acknowledgements at least on the pharmacy side because we’ve got a handle. Gwen says let’s step through this and see if it’s needed or not, let the market mature and tell us exactly what they want from acknowledgements. So what would you have NCVHS do?

MS. MILLER: I think I’ll tackle this one. I want to clarify a couple of things that you said. There is a technical piece to doing EDI that requires at least two of these transactions, which would be your TA1 and your 999, because when an EDI transaction comes in, there are technical things that happen to it. And I put it into very simplistic terms by saying you peel the onion. That’s very, very technical. A lot of times business people never even know that that happens. It happens underneath the covers and they just don’t get it. I mean, it happens in a practice management system because they have to consume technically that data.

When you get to a different level, which is where you’re at the business level and you’re starting – and I’ll give you my example maybe that’s an easier one, which is I’ve sent you a purchase order and I’d like to purchase 10 shirts, and I say, “I want 10 men’s shirts.” I didn’t tell you what size, I didn’t say long sleeve, short sleeve, I didn’t tell you I wanted them blue, I didn’t tell you any of that good business information. But my EDI transaction was absolutely fine, and it went through sailing without a problem until you got to that piece, which is at the business level.

So I think when you’re thinking about these, you’ve got to separate that business side from the technical side that says I physically got this thing and I want you to go back to FedEx. When you go to get FedEx, you don’t think in the background about the tracking that’s gone on, you don’t think about the fact that there really is a receipt, that you can go on line and see the accounting. That TA1 and 999 gives you that very baseline. It should be almost innocuous. And it’s not a turn it on, turn it off. Every person that gets an X12 transaction looks at that envelope. It has to evaluate it because it gives you the markers to go inside and so to the next layer, and they have to do that piece too. Now, if it’s accepted and there’s no reason and trading partner agreements say, “Look, if it’s accepted, it’s fine, I don’t want to hear from you. Only talk to me when it’s not. I’m going to assume it’s accepted,” X12 accommodates for that.

The other thing I do want to be very clear, in the only transaction that is by trading partner, by the sender, is the TA1, that outer envelope. The rest of them are not governed by that flag. It’s only the one and one only, the TA1. It is a unique thing. So I as the sender can say, “You know what? I don’t want to mess with this. I don’t really care. I’m going to put a zero there and you’ll never get it, ever again. I don’t want it. I don’t care what you do to it. I don’t want it.” That’s at the senders. So there’s lots of ability but I think we have to almost put a line in the sand and say, “These things are technical.” And to fill the black hole you need technically to do these because you’re doing them anyway whether you’re sending them or not. You’re going through that motion of peeling. You have to. It’s the only way to get into that data.

The other side of the coin is more the business side, where you’re starting to talk about things like, “Hey, I don’t know who this member is. I’ve already gotten this claim, it’s a duplicate.” I can go through the whole list. So maybe if you can put a dividing line and think of it from a more of a plumbing perspective versus a content perspective it will help with that adoption. You adopt X12 EDI. We made a mistake in 4010. The people didn’t realize when you do this there are plumbing and accounting things that go with our standard that were missed. And now we’re trying to get back into it. If you talk to any other industry, they do TA1’s, they do 997’s. They’ve been doing them for years.

The beauty of EDI is once you have it going it’s rare that it breaks. It’s normally at the content level where they start to have problems. So those things tamp down very quickly. And I could go back to many of my clients and show you where at the very beginning, lots of TA1’s, lots of 997’s, 999’s. Once it gets healthy they’re in the business layer and these things really tamp down and go away and they become a non-event. Does that help you a little bit understand?

DR. SUAREZ: Yes, that helps a lot.

MS. LOHSE: I have two things to add to that. You made the point about how does the system work, right? And I think Lisa did a great job in highlighting all the hops and mentioning the clearinghouses again. So as we – the system, the acknowledgements are not going to work and they don’t get their use unless it goes through the whole system, so you’re going to have to have this across the system. And it is through the providers, the venders, the health plans. And then the value is given because you can see end to end the chain. So right now we have a set of non-mandated standards. People are using proprietary formats. Some people are using the standards, some people aren’t. We have an opportunity and the actual section of 1104 gives us that opportunity as an industry to say what business rules, including the adoption of industry-neutral standards or other standards, do we need to drive these HIPAA adopted standards. And we shouldn’t miss that opportunity. We have deadlines that we can make.

It’s been years, and I think Lisa gave you a timeline about the push to get these adopted on a national level, system-wide basis. Let’s take advantage of the deadlines that are in the ACA of the opportunity. They are transaction and phased approach, and as we roll them out as a system see what works. We’re going to have a lot of technology changes over the coming years and it may be when we get to the 835 things have changed.

MS. BUENNING: I have one brief question. Both CORE and X12 have alluded in their testimony this morning to costs and benefits. We throw around the terms ROI, we talk about the fact that if we overuse acknowledgements that there might be a cost associated with that as well. Do you have any financial information or any data that you could share with the Subcommittee regarding costs and benefits? As we drive towards the deadlines and the ACA, and from the CMS perspective, this is information that not only the Subcommittee needs to have in order to make recommendations but also that we need to have from a regulatory perspective.

So if you could provide that to the Subcommittee, submit it to them after this hearing, and I also would make that note to all the testifiers today. This is really critical. To Lisa’s point, this is not just a technical change. This is a business change. And as such we have to really make sure that the industry is going to benefit from it and that the costs are going to be something that they find palatable. So I would just bring up that point.

MS. LOHSE: We have done a study and it was across 33 million lives for some of the early adopter health plans, six provider offices which were a mix of hospitals, clinics and smaller providers, and then some of the vendors in between, whether they’re more kind of portal venders or clearinghouses. So we’ll go into that ROI study to see what data may be specific, and I know there is specific both – there’s at least qualitative information about the value – and send that to the Committee.

DR. SUAREZ: Thank you very much.

MS. WEIKER: Denise, we, X12 worked with WEDI and I believe WEDI has got some ROI information that Jim or Don Bechtel I think is on deck for later this afternoon, and I think WEDI could supply —

DR. SUAREZ: Thanks so much, Margaret. And I’m sure that question is going to be addressed in later sessions by other testifiers. I just wanted to say, I had like five questions myself but four of those I’ll probably ask those off-line. But I just wanted to say this has been a wonderful, wonderful session. I think Margaret, you clearly understood the need to explain this in plain English and you did it wonderfully. And Lisa and Ed and Wendy, they did a great job as well and presented testimony on these opening aspects of acknowledgment. I think it’s been very, very valuable, so I very much appreciate that. Thank you for your time here.

MS. LOHSE: Walter, I apologize, I want to make one comment with Denise. I was thinking about what she said with ROI. I think we need to think about, as the concept of operating rolls out, is you start taking things out of them. If we remove acknowledgements from the operating rules it starts taking away from the infrastructure. So we really need to make – and this goes back to Michael’s point – a concerted decision as an industry and you as a committee to think about, if you do remove acknowledgements from the operating rules, the value of the other things gets reduced. So we really need to weigh that as we’re moving forward.

DR. SUAREZ: Thank you. We will, certainly. So we are about 10 minutes or so late, but we’re going to take a shorter break. Let’s just take a 10-minute break, and then come back at 10:05 if you could. We have a busy rest of the morning, and we want to make sure that we have a chance to hear all the testimony. So 10:05 we’ll come back. Thank you.

(Break)

Agenda Item: Session 1.2: Provider, Payer and General Industry Perspectives of Acknowledgements, J. Robert Barbour, AMA, Noam Nahary, Montefiore (via phone), Barbara Mayerick, VA provider (written), Greg Fisher, United, Peter Walker, Aetna, Jim Whicker, WEDI

DR. SUAREZ: Okay, it’s about 10:06 and we’re going to go ahead and get started again. Thanks for your indulgence in doing a shorter break this morning. So after this first session on an overview of acknowledgements and some of the references to standards and operating rules, we’re going to go to our second session, which is focusing on the perspective that providers, payers, and other industry groups have about acknowledgements. So without any further ado, we’re going to go into our presenters. And I think we have all the testimonies here with that. So I think we’re going to go in the order in which we have in the agenda. So I think Robert, you’re first.

MR. BARBOUR: Good morning, I’m Robert Barbour with the AMA, and today I represent the AMA and the Medical Group Management Association on our presentation in support of the acknowledgement transactions that have come up to now. Our agenda is pretty straightforward. We’re going to support these transactions. We’re going to give you the physician practice business case on top of the more technical discussions you had for now. And we, obviously from a physician’s perspective we look at these transactions based on what they can do today and we also add what we would hope they could do. So we openly say up front that we will probably be adding functionalities in our conversation that isn’t currently supported by the transactions and/or operating rules. But I think when you see it in context with the vision concept of what we’re going, you’ll appreciate why we’re asking for perhaps other functionalities to be added at a later date, that that does not in any way undermine the value of the transactions and the standards that exist today. It’s just an additive value.

So right up front we want to see that the AMA and the MGMA recommend mandating the TA1, the 999 and the 277CA as appropriate for the associated transactions. And in our case we want to see it every step of the way. Even though we understand the concept of acknowledgement overload, I want to put in context of a question that physician practices ask. It’s a simple question: Where’s my transaction? And if I don’t have every step of the way I may not be able to get an answer to that question. So that’s what we want to know. So if our transaction doesn’t work, and the one that concerns us the most, as you can imagine, is the ones around the revenue cycle, if something falls into the proverbial black hole we don’t get paid. So that’s why we’re so focused and sensitive to this. I’ve already mentioned this piece here.

So our basic concept, to build on the Federal Express model, is if we already have the general concept of asking FedEx or any of the other companies out there, “Where’s my package?” as you can imagine the simplistic question we want to ask is, why can’t one-seventh of our economy ask “Where’s our package?” And I know we say that with some humor, but think about that. We really are talking about the largest segment of our economy not having the ability in a standard way to know where our transactions are. And I think that’s the ultimate thing we’re here to address.

So what we’ve asked ourselves is, are there any examples of where this works today. I don’t know if you can see this clearly but this was my attempt to show what happens when it does work. And the clearest example is when a physician’s office or practice sends a transaction directly to the end receiver of it. In this case, this was our example of sending a claim. All of the transactions and all of the feedback loops you’ve already heard give back to the provider, to the physician practice, the answer to the question “Where is my claim?” We know every step of the way.

If you see where those transactions occur, where it is, all the way up to the point in time where we get the ultimate transaction, the remittance of the 835. So we simply ask ourselves the question, just because we start to make this process more complicated why would my need for that information diminish? Shouldn’t it go up with the complication? So again, that’s what’s driving our conceptualization of supporting these standards today.

So we try to come up with an interesting way of looking at it when it gets a little complicated from a provider’s point of view. So if we start at the bottom left side, we send claims out to either what some people call a gateway – often systems have their own mini clearinghouses or it might go to a true first clearinghouse, but in this example we’ll just call it a gateway, who then sends it to step two, which is a clearinghouse, which could be one of the main national ones or a regional one, who then sends it to the payer’s clearinghouse, and then finally it goes to the payer.

Without any kinds of transactions it looks like one of those shell games that we all see in New York: Guess where your transaction is? And ultimately we could end up saying we think we know where it is. And as the last line shows, guess what? It wasn’t where we thought it went.

So what happened? How can that happen in this drawing? So in step one, we sent our claim to our gateway, they send us back – even though it’s proprietary, they send it back by carrier pigeon that we definitely got your claims, everything’s fine. So from the provider’s perspective they think it’s going to work well. They are oblivious to the next two steps. That’s the key. They are oblivious to the next two steps. So when step one goes to step two that transaction there could work fine. In our example that’s what happened. So step two is a really good player. They do everything the way we want it, albeit voluntarily, and they tell step one everything’s fine.

Now, step two sends it to step three. They get minimal information back, but because the role of step three is to dive deeper into the transactions, they actually ended up with a bunch of issues. And as a result of that in this hypothetical, step four, the ultimate payer, never got the claims.

So from a provider’s perspective, as we see at the bottom, ah, all my claims were sent and everything’s fine. If they’re not using other transactions, they’re just doing what the norm is, then the next thing that they’re going to realize is, what happened to my payments. So they may call the payer and then be told, “What payments? We never received the claims you got.”

And so we called the first gateway or clearinghouse to say, “What happened? I thought everything was fine?” And now we’re off on the treasure hunt. So that’s how providers see the scenario and with that in mind, when we ask how much is too much in acknowledgements, that’s where we’re coming from.

So simply put we feel that the acknowledgements as they’re laid out, and we heard today, need to occur every step of the way as appropriate. So obviously if a 277CA is not appropriate between step one and step two that would not occur. But if the provider, the physician wants to ask themselves, “Where’s my claim?” we think that some information needs to come back for them to be able to answer that. That is what we’re trying to attempt to show in these blue loops. I don’t believe that they are in the existing standards. But unless and until we’re able to capture that information, we cannot ask that ultimate question, “Where is that transaction?” So that’s what we’re trying to say here.

But even without that, having the appropriate transactions in between, which is being presented today, is a major value add. And as I may repeat myself a little bit later on this, the reason it is, is that we do have examples in certain states where this is being already mandated, that just making everyone do that properly by its very nature may make the black holes in between disappear. We’ve also talked to other areas around the country where that doesn’t appear to be the case, so that’s an open question that we still have to resolve ourselves.

But we are not at all asking for information overload. We only want the information if it’s needed and it’s justifying a purpose. So from our point of view, until it is proven that we don’t need it, we’d like to have it. And that proven doesn’t have to be longer than three, four, five, six months. If the industry steps up and it works fine, we don’t want the information overload. So we’re not looking at it to be a lifetime endless loop, but we do need to know what’s happening.

Now this is just in this case. Think about what happens when we add COB. Same things as just happened but now, if you have the COB where the payer sends it to payer two, we are totally out of that loop today and the only way most physician offices know what’s happened, again, is the aging of the receivable. And although there may be a better way, the norm is they will drop a claim to payer number two to say “What happened?” or get on the phone or what have you. So in our grand scheme of things we really believe that if we ever do develop payer to payer COB, which is not the worst idea by the way, we would like that audit trail to come all the way back in some creative fashion that again could answer that simple question, “Where’s my claim?”

So pretty much when we at the AMA and the MGMA looked and researched out, as you’re hearing today, there’s a pretty strong consensus of the value of acknowledgements. So we’ve already mentioned, there’s a question on whether every step of the way is necessary. We point out that local experiences drive that difference of opinion, and our recommendation on that is perhaps we ought to have a pilot project to assess the value and audit trails.

We also want to make some industry observations of who’s already on first. And we notice that Medicare has already decided the value of TA1, 999 and 277CA since the beginning of this month, so that’s an interesting observation. We have several states out there that have statutes or soon will have statutes mandating the use of these transactions.

The IAIABC’s National Workers Compensation eBill also recommends these transactions, and they pointed out to us how critical it is, and it’s in our written testimony to you how critical it is for their late payment laws to identify the source of the delay. And it turns out to be a key component for them on encouraging the use of EDI, again, where’s my claim, who’s got it, et cetera. So again, it’s a pretty straightforward value from a physician’s perspective.

So our last question is, because this thing is being so valuable to us, is there any way to expedite its adoption. So we don’t know if it could work as an interim operating rule while the standards are fully acknowledged, but we ask you to think creatively and help us, the industry, see if there’s a way to expedite its value because I’m pretty sure you’re going to walk away hearing a strong consensus from the industry that this is important. So thank you very much.

DR. SUAREZ: Thank you, Robert, thank you. So we have Noam from Montefiore. Is he on the phone?

DR. NAHARY: Yes, good morning, how are you? Can you hear me?

DR. SUAREZ: Yes, we can now, thank you.

MR. NAHARY: Great. Hi, this is Noam Nahary. I’m the Director of e-Commerce and Revenues at Montefiore Medical Center here in the Bronx, and as representative of the revenue cycle operations and technology team here at Montefiore I’d like to comment on operating rules from the perspective of my institution, which is an early adopter of electronic transactions. We consider ourselves to be a leader in working with health plans to advance administrative simplification.

Some background about Montefiore – the Montefiore delivery system offers a full range of healthcare services, preventive, primary, specialty, acute, and post-acute, for the nearly 2 million residents of the Bronx, New York and nearby Westchester County. Our annual cash collections are approximately $1.8 billion, which is achieved by a team of 400 full-time equivalents distributed across station registration, insurance verification, billing and reimbursement. Today Montefiore has the ability to submit and receive all mandated HIPAA transactions. I’d like to also mention that we were a pilot hospital with Medicare for testing and development of the Electronic Claim Attachment transaction, better known as the 275.

Montefiore welcomes the PPACA operating rules as it moves the industry closer to realization of administrative efficiencies as these are key indicators of an organization’s ability to effectively manage resources and reduce costs. The vision at Montefiore is to create a no-touch revenue cycle through the use of standardized, robust and uniform HIPAA transactions.

Currently standards healthcare claim acknowledgement are not mandated and have caused health plans to rely on proprietary processes and reports. And I’ll make some more comments about that a little later. The abundance and variety of these non-standardized acknowledgements may not provide enough detail, this requiring manual interventions and work around solutions by providers.

Our experience here at Montefiore shows that approximately four percent of all of our claims are rejected prior to entering a health plan’s adjudication system. As per the version 5010 regulatory impact analysis, which is available on the CMS website, health plans receive more than 4.3 billion claims from providers annually. At a four percent rejection rate, this represents 172 million claims, or administrative efficiency opportunities for the healthcare industry.

Also a 2009 AHIP claims processing survey shows that 82 percent of claims are received electronically and of these 75 percent were adjudicated without human intervention. Standard healthcare claim acknowledgements may facilitate improvement to electronic claims submissions by providers, and also the amount of claims adjudicated automatically by health plans.

In terms of operating rules, standardized acknowledgements should focus on claims submission by providers to health plans and apply to intermediaries acting on their behalf along the claim submission pathways. It comes down to – and I’m going to reiterate what Robert says, which is essentially, providers need to know where the claims are with certainty.

So in terms of recommendations, there’s going to be three. Each trading partner may perform several levels of evaluation to ensure claims are compliant, complete, and contain accurate information to adjudicate the claim. It is critical for providers to know the status of the claim at each step, especially the detailed reason for rejections, to ensure appropriate corrective action by the provider for successful resubmission.

Actually I’m going to outline three key components of operating rules, and it’s been mentioned by several of the previous presenters. The first one is to standardize the acknowledgement format. Health plans and intermediaries and providers should all use the following transactions to communicate exceptions, acceptance or rejections where appropriate – the TA1 the 999 and the 277CA.

In addition I’d like to take it one step further and recommend that uniform use of category status and entity codes be used. These codes are critical for migrating the provider’s manual business office processes away from plan-specific processing and workflows. The operating rules really need to provide clear guidance on common, claim accepted and claim rejected scenarios. Operating rules need to provide uniform usage of the code combinations representing these common scenarios on standardized acknowledgements.

And lastly, claim level reporting for standardized acknowledgement should be provided at the claim level for both the 999 and 277CA. Montefiore, as an active participant of CORE, Linksys, X12 and WEDI, recognizes the collaborative efforts of these workgroups as an excellent starting point for further refinement towards operating rules for standardized acknowledgements.

With that being said I’m grateful for the opportunity to submit this statement, and I just wanted to mention a few things in terms of what providers are seeing on a daily basis. In today’s word essentially payers and providers have been covering the black hole with a myriad of different patches to provide the information to providers when the claim rejects. We’ve seen varying versions of the 277 transactions, we’ve seen 999’s, 997’s, TA1’s. In addition there are scenarios where providers must go to payer-specific websites to get that information, and in some cases providers have to access payer legacy systems to get that information. And lastly, there are still instances where payers cannot provide any of that information electronically and we’re still getting paper letter rejections.

It’s encouraging, though, that with 5010 a lot of health plans have announced their intentions to move toward the TA1, the 999 and the 277CA, so I agree with the consensus that it’s very important. It’s a widely-held practice that everybody’s doing something. I just think we need to get everybody on the same page to do that something which is standardized. So that’s the end of my statement. Thank you very much for letting me comment.

DR. SUAREZ: Thank you very much for the testimony, and if you could stay on for some questions at the end of this session we’d appreciate that. We’re going to go next to Greg Fisher.

MR. FISHER: Thank you. My name is Greg Fisher, Director of Interoperability and Data Standards at United Health Group on whose behalf I present these comments. Many of the things I had written in my testimony have been covered by X12 and others so I’ll skip where I can to save time. I want to thank you for the opportunity today to offer comments on the transaction acknowledgements. Our comments will focus on the benefits and issues facing implementation and use of standard acknowledgements.

From a payer perspective, transaction acknowledgements are a double-edged sword. They have a strong potential for providing a smoother automated process for electronic transactions, but the rules for usage are currently poorly described and inconsistently applied nationwide. At least three states have mandated claim acknowledgements, none of which are based exactly on X12 and recommendations. Often claim acknowledgement requirements and rules are written in state regulations that were originally designed to apply to a paper claims world, and don’t always track well with EDI realities. We also see that non-HIPAA X12 transactions such as the 275 attachment and the 278 notification, could use standard acknowledgments and should be covered under any consideration if possible.

We also see a clear difference between batch and real-time acknowledgements and believe the differences should be carefully analyzed and accounted for in any regulation. We also see a risk in adopting acknowledgement transactions that may cause unnecessary retransmission of transactions. The purpose of acknowledgements, we believe the primary reason is for a confirm receipt of a transaction. There are also some situations where an acknowledgement may be extended to report of a transaction’s acceptability to the receiver, such as a claim transaction acknowledgement. A standard set of acknowledgements coupled with standard operating rules will help reduce administrative costs through better automated handling of electronic transactions.

It’s been covered already by the Expo folks what the transactions are. I won’t cover those specifically but it’s important to note that each X12 transaction has its own set of acknowledgements. Some are designed to respond only to the immediate sender, others are for the original submitter. For instance, the 277 claim acknowledgement and the 824 application advice are designed to go back to the original submitter of a transaction. All the 999 and TA1 are designed to go back only to the immediate sender of the current of the current transmission.

For 277 claim acknowledgements we believe that the 277 CA provides the most immediate benefit to the industry. If the adoption of this transaction is to do a final rule or operating rule on the current schedule, however, it could take five years or more to implement. This timeframe should be revisited. This transaction can provide affirmation that the claim reached its destination and was accepted or rejected by the payer.

The 835 Remittance Advice provides a unique challenge to payers. The normal acknowledgement would be a TA1 and 999 combination – and I want to note a typo here, just to say TA1 is showing an unsuccessful transmission and the 999 reporting on TR3 compliance. There is no process today to cancel an EFT or a check and reissue an 835 because of a TR3 implementation violation if the payment amounts are correct and usable. Because the payment may be deposited and cashed before an 835 or a corrected 835 is reissued, great confusion could be caused if the 999 required an automatic correction and re-issue of a payment. 999 acknowledgements should be used to confirm successful receipt only. If the receipt is not confirmed then the original 835 can be re-sent.

Non-HIPAA transactions – there are certainly others that could be appropriate here. Some such as the 275 attachment are scheduled for future use and they’re named in the regulation. Others such as the 278 notification and 278 inquiry may be named and adopted in the future. We urge NCVHS to recommend that acknowledgements be strongly encouraged for additional X12 transactions such as the inquiry notification, the 277 request for additional information coupled with the 275 attachment.

We recognize that there are several states that have existing acknowledgement requirements, and these states may cause issues in a national approach to acknowledgements. For instance, New Jersey requires a pre 4010 version be used for claim acknowledgements. Texas requires that even if one claim in a batch is valid it needs to be passed on even if the others in that batch are malformed or unreadable electronically. Strict reading of this law caused United Health Group to create an additional proprietary 997 acknowledgement transaction in 2005 to comply with that law.

Minnesota has a complete set of acknowledgement requirements that while comprehensive may not be the same as the events rule national approach, and it’s not clear if all the Minnesota acknowledgements need to be adopted simultaneously, or on what schedule. In many states the rules for acknowledgements were written when the vast majority of claims were sent on paper and thus their laws often represent a paper-based process. For acknowledgements to work properly there needs to be a national electronic acknowledgement standard, not a series of state standards.

Timing of acknowledgements implementation should be scheduled with other industry deadlines in mind. As mentioned previously the operating rules for claims are not scheduled for almost five years so it might be feasible to mandate that 277 claim acknowledgement be done earlier. In light of health plan ID and ICD 10 mandates in 2012 and 2013, respectively, the scheduling of the 277CA might best be scheduled for a separate date. The Minnesota requirements for acknowledgements take effect in 2012, so the industry may be able to benefit from seeing how this implementation plays out when planning for the national schedule.

The batch versus real-time discussion has already been handled very well by the previous presenter, so we won’t go through that. We also believe a standard should be chosen for real-time claim adjudication acknowledgements. For its real-time adjudicated claims United Healthcare uses a 277 claim acknowledgement only if a claim cannot be immediately adjudicated and actually sends a preliminary 835 for successful real time adjudication. And that acts as the acknowledgement for a fully-adjudicated real-time claim similar to the prescription drug business. While this makes sense to us, it may not be the way others would build real-time claim acknowledgement capability.

We do have some concerns as well about terminology. For instance, the term “unsolicited 277” is not necessarily the same as a 277 claim acknowledgement and the 277 claim status response is not synonymous with the 277 request for additional information, or either of the first two transactions mentioned. The similar naming of some of the transactions, particularly the 277 and 278, can cause confusion among those who are not completely familiar with the X12 naming conventions and could cause implementation issues if improperly defined.

Operating Rules – although the rules for usage are often clear in the X12 TR3’s, it should be recommended that if the current TR3’s are not clear concerning the acknowledgement process, and if the guidance cannot be updated to meet a new regulation, then the industry should look to operating rules to cover the gaps. NCVHS should be aware that operating rules may be necessary and may need to assign an operating rules entity or include this under existing schedule for transaction rules. All the requirements for claim acknowledgements should be considered simultaneously, including the ones associated with the 275 attachments transaction. Since the 275 attachment will most often be associated with complex or high dollar claims, it makes sense to develop the rules and requirements at the same time as the 835 claim acknowledgement.

A primary concern for UnitedHealth Group is the 835 acknowledgement, as previously noted. However, we are also concerned with clean claim definitions and what might be required for a 277 claim acknowledgement for the individual states under clean claim laws. We do not support the use of the 824 application device for claims or EFT, and we do support the use of the 824 for the 275 attachments, as mentioned in the TR3 for that implementation.

Although we realize there are many paths to adoption, we believe there needs to be a review of the implications of a breached transaction. For instance, if the full capability of the 999 when utilized, it could mean creating error messages for parts of the transaction that are not used. That could cause an unintended reduction in the transaction flow by unnecessarily requiring retransmission of transactions.

United Health Group is willing to invest in supporting the transaction acknowledgements for the ultimate automation of the administrative process. We believe it is the right thing to do because transparency and simplification benefits everyone in the long run. We believe these transactions have potential to simplify and standardize the electronic exchange of EDI transactions. These acknowledgements also serve to provide a measure of success for the transaction; however, we recognize there needs to be a careful review of the rules and levels of edits applied to the acknowledgements to avoid a proliferation of acknowledgement transactions that could require extensive rework with little or no benefit.

We appreciate the opportunity to present our response today. Thank you.

DR. SUAREZ: Thanks very much, Greg. We’re going to go next to Peter.

MR. WALKER: Good morning and thanks for the opportunity to talk to the Committee today. I believe the Committee should have a longer document from me with details, but what I’ve prepared to talk to is just a summary of that, but I’ll be happy to take questions of what I talk about or any of the material in the longer document. So let me start by talking about a little bit of background at Aetna and acknowledgements. Since we implemented the 4010 transactions to the original HIPAA date, we have been returning acknowledgements that are based on the X12 standards.

What we did with 4010, Lisa would tell you – and she mentioned some of the difficulties with 4010 – is perhaps not technically compliant with all of the areas in the X12 standards, but from a business perspective it conveys information in the same way. Today we’re processing more than 2 million X12 transactions a day. That includes claims, the real time transactions like the eligibility preset referral inquiry and the electronic remittance advice. In addition we do the NCPDP transactions for pharmacy and electronic remittance advices for those, but that’s not included in that count.

So each of the transactions we receive from the providers is acknowledged using an X12 based acknowledgement, and our web site, our secure provider portal, when that type of transaction is carried out through that website, that operates through transactions using the X12 standard, so the same acknowledgement drives the process used on our website as well as the process used for the electronic transactions themselves.

Let me talk briefly about what’s changing with provision 5010. We’re currently in external testing and we have some 5010 transactions in production. Again, we’re following the guidelines, the X12 standards and the WEDI guidelines that Lisa talked about. The quality of what we can do and the cost of implementing it is being improved by the greater specificity in the implementation guides. That means that we’ve received better quality software from our translator vendor which applies the software that drives the initial receipt and acknowledgement process. And that reduced the amount of work we needed to do to get that set up. So basically it’s easier to do the X12 acknowledgement standards with 5010 than it was with 4010.

So what have we learned from this use of acknowledgements? We know that all of the providers and the vendors who send us those separate transactions can support X12 standard based acknowledgements, because that’s what we’re sending, and we deal with most of the providers and vendors in the country. We know that the code sets that are used within them, that’s the standard codes that Norm referenced, convey the information that people need because those code sets essentially have not changed between the 4010 and 5010 versions and we’ve been using them since 2002. We think there’s room for some further improvement in the industry implementations of what’s considered an error when a transaction is received, and therefore would result in a 999 rejection being returned. And I put more information about that in the detailed document to the appendix.

I’d also like to point out that in the flows that are being talked about, a claim acknowledgement in the 277 claim acknowledgement format used with the 5010, as has been mentioned earlier, that essentially reports on whether a claim was received and whether it was initially acceptable or not. After a claim has been received and been considered initially acceptable it can get into a claim process where it’s found that there’s some additional information, for example, that’s needed. Maybe we don’t have information from the member that we need about a primary payer on COB. Maybe there’s clinical information needed. That claim can then go into appendix status. There’s an additional transaction that needs to be used if you want to report back to the provider that the claim is waiting for additional information. So that’s technically not an acknowledgement that we feel it’s part of completing the loop of providing complete information back to the provider.

So we, based on that we have some overall recommendations. The first is, we think that the acknowledgement requirements should be part of the operating rule requirements for each transaction set so that if you’re bringing in operating rules about a transaction it’s appropriate for those operating rules to require the acknowledgements. That’s the quickest way to get these implemented in a standard way in the current regulatory framework, and it also appears to us to be logical in terms of allowing the industry to phase in its readiness. That doesn’t mean that people couldn’t and shouldn’t implement ahead of the operating rule requirements. If they choose to do all of them at once that’s great, but the operating rules provide us a way to get them in early, and mandate them without waiting for the new laws or regulations.

We support using the X12 standard acknowledgements and the code sets in them. We think that in talking about the code sets, operating rules can talk about consistent use but shouldn’t prohibit the use of any of the codes that have been established. If there are codes that shouldn’t be used there’s a code sets committee that can be asked to remove them from the standard.

To point number three, as Lisa said the failures in the EDI process are very rare. To use the FedEx analogy, it’s extremely rare that we get envelope delivered to us that should have gone to someone else or that that envelope is heavily damaged, or the contents damaged. So what that means is that there’s very few instances in production processing where the TA1 is needed to report an error. Out of our 2 million transactions a day, I asked our people who deal with those kind of errors how often the kind of situation that would create a TA1 reject comes up. And they said maybe once or twice a quarter. So while that’s part of the standard, as long as the next level acknowledgement, the 999 or the application response is then promptly implementing the TA1 may not be a business priority.

Lisa talked about improvements coming to the TA1 with 6020. That might be a good time to consider it.

Point number four, the claim acknowledgement – the 277CA in X12 terms – that’s a vital part of providing claim status to the submitter. That’s basically where the big return on investment comes in, is being able to say back to the provider we’ve received the claim and it’s either been accepted into our adjudication system or had some problem like we don’t know this member. They may have told you they have Aetna coverage but actually they don’t, those kinds of situations. So we think that there’s a CORE proposal to enhance the phase I and phase II rules and the mandated operating rules to include the claim acknowledgement, and we think that’s the best way to get the ROI from bringing in the 277CA. The reason that has ROI is because the provider then no longer has to contact us to find out the status of their claim, which is expensive for them and expensive for us.

So just three final recommendations. I mentioned there’s inconsistencies in how the 5010 999 is interpreted in terms of what’s an error and what’s not an error. There could be some educational work done around that. We think that there should be thought given to including at some point the support of the pending claims status transaction as a standard, and Robert Barbour talked about the situation with COB when what’s called payer to payer COB, when one payer sends, pays a claim, the primary payer sends that claim on to a secondary payer. The situation where that’s happening right now in the industry is when Medicare gets a claim and knows that there’s a supplemental individual policy or a group policy that has further coverage.

Medicare has a process in place to then forward that claim to the other payer, and that generally works great. The problem is, Medicare won’t take, or their contractor won’t take standard acknowledgements, so we, if we find that those claims have a problem we can’t report that back to the provider because that acknowledgement needs to go back up the channel through which the claim came down. And we also can’t report to the provider, yes we got that secondary claim. So that’s an area where Medicare in their contract could potentially look at making some improvements. That’s what I have to say, so I’ll pass it on to Jim.

DR. SUAREZ: Thank you Peter. I think next we have Jim.

MR. WHICKER: Thank you chairpersons and members of the Committee. I’m Jim Whicker, past Chair of WEDI, the Workgroup for Electronic Data Interchange located in Reston, Virginia. As you know, WEDI is an association of corporate, government and individual members that are representatives of the spectrum of healthcare industry stakeholders. And also WETI is designated in the HIPAA Act and subsequent enabling regulations as an advisor to the Secretary of Health and Human Services o HIPAA administrative simplification implementation matters.

I’m here today to represent WEDI. I’m also employed with Kaiser Permanente, and in addition I serve as EDI liaison for AHIM, which an association of healthcare professionals in the financial services arena. On behalf of WEDI I’d like to thank you for the opportunity to present testimony today, and as a side note, as someone who’s worked in the actual implementation of HIPAA transactions, this is a subject that’s near and dear to my heart.

Also it’s an issue that’s very important to WEDI. I would like to note that in the 1993 WEDI report, which kind of started a lot of this going on, the report suggested that the industry adopt standard acknowledgements, so on behalf of WEDI I’d like to wish acknowledgements a happy 18th anniversary. In March of 2004, WEDI also wrote to Secretary Thompson suggesting that there be a requirement for acknowledgements and standard error reporting, and then on May 26, 2004 WEDI wrote to Dr. John Lumpkin, Chair of NCVHS, and suggested the same need for standard acknowledgements and error reporting? Then in April of 2005 I had the opportunity to testify on behalf of WEDI to this committee that there was no standard for acknowledgements of a claim that indicates acceptance or rejection and why, and recommended that NCVHS support that effort to encourage the adoption of acknowledgements, and that for claims this must happen as soon as possible.

Over the next couple of years, WEDI collaborated with X12 to develop a white paper with recommendations for acknowledgements, for not only claims but for all adopted HIPAA transactions. WEDI met with leaders at CMS at the time to encourage their adoption of acknowledgements, and obtained assurance that once the jurisdiction process was in place, CMS would adopt the recommended acknowledgements for claims. CMS has fulfilled that commitment with the adoption of 5010 by adopting the 277CA.

Then again in August of 2008 WEDI sent a letter to Kerry Weems at CMS, once again indicating the need for acknowledgements and submitted our White Paper that had been developed.

WEDI continues to operate an acknowledgements task group as indicated in the letter. The WEDI acknowledgement sub workgroup is working to identify activities, risks, and others, and solutions associated with the implementation of the new standard acknowledgement framework, and associated return on investment as a result of implementation.

CORE wrote to Secretary Leavitt in 2008 regarding the need for acknowledgements, and then in 2009 we had the Affordable Care Act, that also indicates a need for acknowledgements and the additional transactions for the industry. A key element to make all this work is education to all parties, in particular providers and their practice management vendors. This is needed to help them understand the value that standard acknowledgements bring, and the responsibility providers have to review the messages received before contacting a payer or clearinghouse for clarification. Once the issue is identified and resolved, providers and other entities need to understand that when appropriate electronic resubmission is preferred over a paper process or a phone call.

WEDI hopes that by standardizing the process appropriate system changes will be implemented by system vendors. Education to providers will then occur. When transactions do reject providers and other industry trading partners will be more apt to resolve and resent rather than default to manual paper and phone processes to resolve the issue, thus eliminating more expense in the industry.

In the 2008 White Paper, WEDI recommended a timeline and tasks to bring the industry into compliance with acknowledgements. Had we followed that we’d be in production today as we implement 5010. While pilots for using the transactions in an ROI evaluation were not completed in an official manner as indicated and payable, current implementation of the 5010 by CMS and many payers bring the TA1, 999 and 277CA into significant industry adoption.

If the need to evaluate a significant implementation of acknowledgements is needed, you can look to UHIN as well as other organizations within the industry. I participated with UHIN while at Intermountain Healthcare for several years and required the adoption of TA1, 997, and 277, what we called FE at the time. It was a UHIN specific 4020 version that we’re implementing in 5010 today, calling it the 277CA. My experience is that the transactions can easily be adopted for relatively little cost. Also we learned that many payers, providers and clearinghouses already utilized these pre-5010 standards for acknowledgements.

In 2007 WEDI conducted a survey related to the adoption of the 5010 835’s. Questions in that survey asked about acknowledgements. Vendors responded that 75 percent of the respondees were capable of utilizing the 997 but only at that time 58 percent of them were utilizing the TA1. Payers responded, and 100 percent of the payers that responded indicated that they utilized the 997 while only 50 percent utilized the TA1, and at that time we didn’t ask the same questions of providers but it may be possible to gather some national adoption information from clearinghouses as many do offer human readable reports, proprietary electronic and/or versions of the 277CA.

WEDI supports the need to standardize the acknowledgement process in the industry and offers the following recommendations. First, WEDI recommends the expedited adoption of the TA1, 999 and 277CA and that appropriate acknowledgement process occur for all mandated transactions as detailed in the WEDI acknowledgement White Paper. The EFT transaction that is now mandated by ACA will need to be added to the table.

Number two, name and appropriate entity to define operating rules for these transactions. Operating rules will work to further standardize and clarify the process. WEDI will work with those who write operating rules as needed to clarify the process, and requirements such as conformance testing except with errors, how to handle errors in an 835, code set errors, and so on. All three transactions are key for adoption and implementation, the transaction should follow the ASC X12N implementation guides and requirements. And there were five further – discussion needs to occur to discuss acknowledgement of claims when the payer to payer COB model is used as has been mentioned already. We recommend to the secretary that WEDI be consulted for recommended timetables for adoption and development and delivery of education in the industry. It is critical that all payers work together to implement the standards in a manner that reduces costs to the industry. And lastly, we recommend to the Secretary that vendors be strongly encouraged to adopt and incorporate these standards into their suite of transactions offered as that is critical for the adoption and benefit to the industry. WEDI offers its service as a resource to facilitate these discussions and to assist CMS and HHS in providing appropriate industry education.

Thank you for this opportunity to provide input on this important topic, and I welcome the opportunity to respond to questions, in particular ROI and acknowledgement overload.

Agenda Item: Questions by the Subcommittee

DR. SUAREZ: Thank you Jim, thank you very much, and thanks everyone in this panel for terrific testimony and for even getting us five minutes ahead of the end of this session, which will give us more time for questions from the Committee. So I’m going to open it to Committee members. I know Raj from our phone who’s joining us on the phone had a question. Raj, do you want to ask the question? Are you on? Oh, he’s off, okay. He just wanted to pass this question so I’m going to read it, and this is regarding just general information about how many claims nationally are processed without human intervention. This is more of a general question coming.

I think, Noam from Montefiore pointed out to some statistics about the volumes of claims processed and kind of a projection based on their experience of how many claims would potentially require some acknowledgement based on just a four percent rejection of claims. But his question was more about how many, what percentage of claims are actually today processed without human intervention. Anybody wants to venture to –?

MR. WHICKER: I could proffer a comment on that. I can’t say these are hard and standard statistics but I do know when I had discussions with our health plan site at Intermountain, that at one point they claimed that 60 percent or more of their claims hit what they called first pass adjudication. Standard things such as lab tests and therapies and so on that didn’t require a lot of claim development would go through their automatic adjudication, and so you could say without human intervention on the provider or the payer side, that once the claim was generated by our billing system past our edits, past the EDI, went through their first pass adjudication and process for payment, that they would indicate at that time 60 percent.

MR. NAHARY: This is Noam Nahary. Just to clarify, the numbers that I was quoting are available in a 2009 AHIP claims processing survey, and the link is available in my written document.

DR. SUAREZ: Great, thanks. Yes, Peter?

MR. WALKER: Yes, in getting to the point where that 277 claims acknowledgement is generated in order to indicate receipt into processing or initial errors, electronic claims, that’s 100 percent automatic so there’s no manual intervention to create that 277 claim acknowledgement. Then as the claim gets into processing there may be some claims that stop briefly because a human needs to look at them to interpret it, or a role that is coded, is capable of being coded in detail in a claims system, then there’s a small percentage of claims that as I mentioned, pend because additional information is needed and it’s stopped until we get that additional information. But the majority of claims – 100 percent of claims, we could generate that claim acknowledgement automatically, and the majority of claims can flow through untouched.

DR. SUAREZ: Thank you.

MR. FISHER: This is great. The only thing I’d add to that, just for a number, United Health uses a number just a little higher than 80 percent for claims that go through auto-adjudication.

DR. SUAREZ: And Robert?

MR. BARBOUR: I just would like to remind the panel that not all the payers are of this caliber, and we have challenges that go across the spectrum, and what gets caught. One example that’s in our written testimony I’d like to share here is the fact that some payers today will affirmatively acknowledge what was a problem, and ask you to impute that the remainder of the transaction was not a problem, and we have found in other settings that when queried later on or what happened to those imputed claims downstream, that sure enough a subset of them were acknowledged by the payer to have never been received.

So the amount of manual work that goes into these processes, there’s more than you might think. And what we found was that the reason those things were deemed not to be received is that they had gone into work queues before the front door of the payer to be looked at and for a variety of reasons such as staff came and went, those work queues weren’t worked and fell into what we as the provider’s side of the house call a black hole. So there’s a lot more to it than what you just might see.

DR. SUAREZ: So some questions from the Committee? Jim?

DR. SORACE: Just out of curiosity, for those claims that do go through rapidly, is there still a value in an acknowledgement if it gets paid within a reasonably short length of time. So if it was submitted at a near real time it gets adjudicated and paid.

MR. WHICKER: I’d like to answer that. There was a little bit of discussion in the previous panel about the acknowledgement overload and that kind of ties to the question that you’re asking there. And the example that I would use is, when I was preparing for a presentation at a WEDI conference about acknowledgements, I pulled one day’s worth of acknowledgements for Medicare for our physicians group. Five thousand claims had been submitted the day before. If I printed out the entire acknowledgement manual report that came through, that was 1,500 pages, 1,500 pages of acknowledgement data, of those 5,000 claims only four rejected. Now they could have been a $25,000 surgery claim or something but there were only four claims rejected, but we had to search through 1,500 pages of data to find those before they’re rejected.

Now yes, we could wait for the payment to determine whether or not the claims got in, but then you’re in the process of saying, well, 60 percent of them got paid so I can pull those out. Then I’ve got the other 47 percent that I need to go through and figure out which ones did make it but are still pending on the payer’s side, and of those which ones don’t they have.

And so the concept about acknowledgement overload for me is an issue. You need to look at it from the perspective of working the exceptions. And if I have 5,000 claims that are submitted and I get 5,000 acknowledgements, I want my computer to deal with the 4,996 and just tell me the four I need to follow up. And let’s let the computer do what the computer can do, and the EDI system do what it does as well and then let those four rejections be handled by the staff. So for me it was never an acknowledgement overload. It was really more working the exceptions as they come through.

DR. SORACE: And I was also just curious. I’m going to payer if it’s a rejection out, or an acknowledgement out, say. I’m saying that there was some difficulty. What are the uncertainties on the return journey? It traces through several layers of intermediaries there, and do we have a good idea as to what the delay – and other people can actually interject delays, so do we have any idea as to what we need to consider about on the return journey, at least, acknowledgements. Especially if they contain race problem issues.

MR. NAHARY: This is Noam Nahary. I’d like to comment on that.

DR. SUAREZ: Sure, go ahead.

MR. NAHARY: Essentially providers will either submit their claims – and I’m going to focus on claims, because I think that’s again where the most ROI is, at least at this point. Providers generally can either submit their claims directly or via intermediaries. And essentially whether you’re going through an intermediary to the health plan or directly to the health plan, every step in the process is going to evaluate for completeness, for accuracy, for anything inappropriate, and it’s important that at every step in the way the providers can receive standardized, robust information.

If a provider mainly deals with 10, 20 plans for most of its patients, that’s 20 different possible sets of rejections and codes and variations in terms of the methods of delivery and the type of information that comes back. It is overload in today’s state, given that we have so much variation and lack of standardization. So it’s imperative, as Jim said, to be able to identify the exceptions quickly so the claims can go in and get resubmitted, and then ultimately every step along the way, going from the provider to the intermediary to other intermediaries and ultimately to the health plan, you have to really have that handshake to say, you know, it’s going through successfully. This way the phone doesn’t have to get picked up to say, “Is it actually there?”

MR. WHICKER: And that’s something that I hope the operating rules deal with, is that need for the chain of trust between entity to entity to entity and those timelines are compressed down. And I don’t need to worry but I’m sure Robert has a comment on this as well.

DR. SUAREZ: Peter, do you have a comment?

DR. WALKER: This is Peter Walker. I think Jim Whicker’s comment about his 5,000 claims that generated 1,500 pages of report acknowledgements is an excellent example of why we need a standard electronic acknowledgement process, because without that he gets these paper reports that he has to look through. He doesn’t have control over how they’re formatted or sorted, so his four rejects are buried in 1,500 pages. If he wanted to look and see, well, were there any claims that they’re not acknowledging, he has to manually match 1,500 pages of paper to a listing of claims. It’s impossible. If he gets the standard electronic acknowledgement, he can match that acknowledgement against a claim in his system and he can generate whatever information he needs to tag any claims that weren’t acknowledged or any claims that were reject, and just the items of interest can come out and be dealt with. The others they know are being successfully accepted.

But to address the earlier point about are the acknowledgements needed if you have a fast process, I would say “yes,” because if it’s a fast batch process, if it’s following the – it’s just that some claims may go through an automatic adjudication and get paid faster than others. At the point we receive the claim, we don’t know which ones are going to go through quickly and which aren’t, so we need to acknowledge all of them regardless of whether the follow-up response, which would be the remittance advice, would be coming out within, say, a day or two anyway. If we’re talking about true real time where the whole cycle is completed within, say, 20 seconds, then yes, you wouldn’t send a claim acknowledgement if you knew you were going to be able to send the final product.

MR. FISHER: This is Greg Fisher. I would just reiterate that and say yes, for all the claims you would want to send transaction acknowledgements. And I just want to clarify again that there are two types. There are point to point acknowledgements that go back to the submitter that you just got the transaction from – that’s the TA1 999. Those have to be mandated for every handoff of that transaction, if it’s one step or 92 steps. Each one has to have that point to point response thing, yes, I got your transaction, your file. The other one that goes back to the submitter is the 277 claim acknowledgement. That’s the only one that makes its way back all the way through the chain back to the original source. So it’s not an issue of all acknowledgements need to go to all people. It’s one type needs to go point to point, and the 277 needs to go back for all claims, back to the original submitter.

DR. SUAREZ: Thanks. Bill, you had a question?

DR. SCANLON: Yes, it’s actually about a point that Robert brought up about Medicare starting at the beginning of the month. How would you – how close is what Medicare is doing to the pilot who also recommended? What’s missing from what Medicare is doing?

MR. BARBOUR: Well having not been a recipient of that, I can speculate that at least what’s been described to me is that they’re doing basically what we would expect the transactions to be doing, although I don’t know specifically if they’re doing the affirmative piece that I was talking about. In other words, you don’t infer but I’m led to believe they are being affirmative. So if you’re looking to them for a source of experience that might be a very interesting thing. Jim, do you know anything more on that?

MR. WHICKER: My only concern that I don’t believe has been addressed, that’s been discussed today, is the COB portion. When Medicare sends a claim to a secondary payer and the provider not knowing where that’s handled. Now in the 835 currently there’s an indication of crossover, but if the claim crosses to more than one payer, there’s not an ability in the 835 to report the additional locations. But a very clear communication of the submission of a COB claim in the payer to payer model is needed, and I don’t think that’s in the current implementation.

DR. SUAREZ: Any other questions? I do have a couple.

MS. MILLER: I can actually answer some of that question.

DR. SUAREZ: Oh, Lisa, please, yes, if you could join us.

MS. MILLER: I was back there raising my hand. A couple of things on what was just asked. When you’re talking – and I’m going to answer two different questions here – when you’re talking about these multiple hops one of the things that’s very important to understand is the mechanics of EDI and how it goes through. I want to take you back to FedEx a minute. When you get that envelope, you open it up, you have your – as you’re going through and you go to a clearinghouse, and I loved Robert’s slide, is that you take off that envelope, you’re inside the functional group. A lot of times the providers or the billing services will send and it’s to multiple payers, so they do this decombination. And when they do that, they’ve actually created a whole new interchange with a whole new functional group, so you’re down to that claim is your business unit that you can track.

And it is correct that those TA1’s don’t work. If we had our providers sending their functional groups that say, “This is to one payer,” then that that functional group could stay intact, and you could start using things like a TA3. There are other acknowledgements that we can look at this, the way other industries work. So I think that’s one thing to say is, it’s the way we’ve implemented that we’ve made it more difficult for the acknowledgement model. And you as a sender really control your acknowledgement model.

To the CMS question, there are a couple of things. TA1, they did it a little bit different than perhaps was recommended by X12, but we’re really happy they’re doing the TA1. The other thing, too, with the coordination of benefits, if a claim comes in and that claim is sent off to another payer, the 277 actually has the ability to say we forwarded it on to another payer. And so there is a code within the 277 that says, “Yes, we got it, but we need to send this to somebody else” so that there is somewhat of a trail. But again, more work needs to be done around that, and that 277 can come back to the provider alerting them that at least that hop had been made.

The problem that you have is, once it’s over there, that new payer doesn’t know who to send it to because they weren’t the ones that got it. It’s actually now being sent by another payer. So it’s understanding the workings of EDI, understanding the transactions, that impacts your acknowledgement model, and how you initiate it, you have more control as the sender than you realize. If you send poorly, you’re going to get poor acknowledgements returned. If you take the time to plan this well, then you get much, much better quality acknowledgements. Does that help?

MR. WHICKER: And Lisa, to clarify, you mentioned the 277CA has the ability to report, but I don’t think the Medicare implementation of that implemented that piece of there.

MS. MILLER: That is a correct statement. I was just trying to be very polite.

MR. WHICKER: We love Medicare for implementing that.

DR. SUAREZ: I do have a couple of quick questions. The first one is to payers. Do you have – we’ve heard those terms before – do you have companion guides associated with acknowledgements, of the implementation of acknowledgements today? Are they being used today, companion guides, or are they not?

MR. FISHER: United Health Group has companion guides, but not separate for each acknowledgement. The companion guides describe, for instance, the claimed companion guide will describe the acknowledgements, and then there will be eligibility transaction companion guide will describe the acknowledgement process. There’s no separate guide just for acknowledgements.

DR. WALKER: Yes, we have companion guides essentially in two sections. One part talks about what someone needs to do generally to interact with us on transactions, how to transmit, and what kinds of acknowledgements we will provide, and then for each of the individual transactions like the claim or the claim status inquiry, then we’ll have a section that speaks to anything that isn’t adequately covered in the X12 implementation guide. So we speak to acknowledgements in our companion guides but we don’t have companion guides specifically for acknowledgements.

DR. SUAREZ: Jim?

MR. WHICKER: I can slip my ROI comment in here on this. As a provider, when we went from pre-4010 EDI to 4010 EDI under the HIPAA model, at my previous employer we were able to go from 10 to 12 FTE’s that were submitting electronic claims, down to just two FTE’s when we standardized the process using our UHIN connection with standard acknowledgement requirements. And a big piece of what they did every day other than pushing buttons to send files was going through and matching claims submission to claim acceptance, and finding those missing batches, those missing claims, and starting the process to resubmit the claims that rejected.

As we moved further into implementation of 4010, connecting with clearinghouses that also began to send standard acknowledgements and more payers doing automated processes with us, we were further able to reduce from the 10 to 12 down to two, and then from two down to one, to when I left we had a half an FTE. And most of that half an FTE was just dealing with those payers that didn’t do the standardized processes. And at United each payer had their own individual way of doing acknowledgements, and it’s great payers do them, and the vast majority of payers do do acknowledgements, even though we had one that said, “We’ll let you know if there’s a problem.” Well I said, “How do I know if there’s a problem if I don’t even know that you got my batch in the first place?” So the positive acknowledgements are key, but standardizing that allows you, if you’re handling your EDI the way you should, to eliminate staff, eliminate that involvement and let the process true up so that you only deal with those exceptions. And that’s where the ROI for me, as a provider, came into play.

DR. SUAREZ: And one last question very briefly, to payers also. What’s your experience with the application of acknowledgements in the pharmacy transactions? We heard from NCPDP certainly that that’s something that is not frequently used or necessary in some of the specific transactions. So from your perspective as payers receiving transactions from pharmacy, what’s your view on acknowledgements for pharmacy transactions?

DR. WALKER: I don’t personally work with the pharmacy transactions, but my understanding is that the process that’s laid out by NCPDP includes appropriate acknowledgements that are already implemented. The area where I do get involved is after the processing of the pharmacy claim has been completed and the pharmacy has received their real time response, in order to, at the end of the week we send out the payments for those and an 835 is created to accompany those payments, and what we’ve found is that the pharmacies don’t want to send us the 999 acknowledgements for those 835’s, which we want to get those because we have a strict production control process. We want to make sure that what we have sent has been received. That has to be done manually if we don’t get the acknowledgement. So the only area that I would say that pharmacy at this point is lacking, is in its ability to just provide that initial 999 acknowledgement to say yes, we got the 835.

MR. FISHER: The other thing that I would add would be that I alluded to it when we talked about the real time claims adjudication, the real acknowledgement for a successfully adjudicated medical claim in United Health Group’s perspective is the preliminary 835. It’s not the actual payment, it’s just an 835 coming back real time, saying this is your payment. In the prescription world it’s not an 835, it’s a different transaction saying, “Yes, here’s your payment.” So from that perspective it’s the same function being performed but by two different transactions.

DR. SUAREZ: Okay, well thank you very much again to all of you for your incredible testimony. We really appreciate that information. So we’re going to move very quickly to our last panel of the morning. We have four presenters. I know one of them, Susanne, is going to join us by phone, and so we’re going to ask those that are going to be presenting here if they can join us here at the table and in the meantime we’re going to ask Susanne to go ahead and introduce yourself and if you could provide us your testimony.

Agenda Item: Session 1.3: Other perspectives of acknowledgements, Susanne Powell, Emdeon, Doug Bibrey, SSI Group, John Kelly, NaviNet, Shelagh Kalland, MN AUC.

MS. POWELL: Wonderful. Walter, can you hear me all right?

DR. SUAREZ: Yes, we can, thank you.

MS. POWELL: Very good. Good morning everyone. My name is Susanne Powell and I am the Director of Government Affairs for Emdeon, and hopefully you will not be able to hear the thunder in the background here in Nashville. We’ve been having some very bad weather and it has just started to move in again, so if you hear any noise or are having difficulty hearing me, please stop me and let me know.

DR. SUAREZ: We’ll acknowledge that.

MS. POWELL: Wonderful. I also wanted to mention that I’m joined by Debbie Meisner, who is Vice President of Regulatory Compliance Strategy here at Emdeon. Emdeon is pleased to submit the following comments to the National Committee on Vital and Health Statistics, Subcommittee on Standards, for its important discussion on standard transactions for acknowledgements. We want to thank the members of the Subcommittee for your time, and we hope that this information will be beneficial to you.

To run a network that powers much of the U.S. healthcare system, as Emdeon does, we must ensure that data moves quickly, accurately and securely between all the healthcare stakeholders. We believe acknowledgement transactions play an important role in improving and expediting the healthcare information workflow, and that standardization is essential in promoting greater adoption.

Today we’ll share perspectives on the value of acknowledgements and fostering large scale information exchange, and the impact of specific content within those acknowledgements on the various stages of an electronic data interchange EDI transaction. And in an effort to make our comments more practical and specific we’ve provided simple use cases within each of the EDS stages to help illustrate the process.

As has been well stated throughout the morning, the primary role of an acknowledgement transaction is to provide confirmation that the electronic transmission has arrived at its destination and is ready for processing. Acknowledgements may contain varying degrees of information depending on where they are used in the EDI process. When HIPAA was enacted in 1996 the legislation recommended the use of acknowledgements and suggested multiple formats but it did not mandate the use or the standardization of the transactions. Thus, the use of acknowledgements varies greatly among payers, providers, and other healthcare stakeholders.

Some use a basic acknowledgement of receipt such as the TA, X12 TA1, while others use a more comprehensive response such as the X12 277CA, as we’ve discussed this morning. But some provide no acknowledgement at all. At the same time, the formats and the data sets of acknowledgements are often inconsistent, making it difficult to use and respond to them effectively. There’s also a wide use of proprietary reports to provide status of claims in human readable format. Requiring the use of standardized acknowledgements at specific points in the EDA process would help to improve both workflow and cash flow for the healthcare industry. I would like to speak a bit about how Emdeon is using acknowledgements, and then I’ll provide you some specific use cases.

Emdeon utilizes the full range of acknowledgement transactions. We’ve consistently advocated for the use of acknowledgements by our payer and provider customers and we’ve participated in CORE and WEDI acknowledgement workgroups as well as conducting outreach through White Papers, webinars, and in particular our HIPAAsimplified.com website. The HIPAAsimplified.com website does provide very specific guidance to submitters and payers on the importance of utilizing acknowledgements and on Emdeon’s procedures for handling them. And in the written document that you’ve received from us we provide detail, and I am going to run through some examples of the guidance that we provide.

For example, submitters are advised that Emdeon will provide a 5010 TA1 acknowledgement if it’s requested by the submitter. We’ll also provide either a 999 or a 997 based on submitter preference. Emdeon will advise a sending trading partner of syntax errors only when Emdeon cannot technically accept a file because of critical syntax errors. We will accept files and transactions whenever technically possible for downstream validation resulting in an Emdeon claim level rejection or clean claim to the payer. But important to note, we will not report any implementation guide rule errors in 999 reporting. We will provide claim level clearinghouse validation reporting of the acceptance or rejection status of the claim, and there are a number of reporting options that we make available to our customers. One option is to get reporting through our Emdeon vision for claim management software product. We also offer machine-readable reporting. We will utilize the 4040 version of the 277CA as well as the 5010 version of the 277CA, and both versions will include support of claim level STC12, i.e., freeform text, and that will be used to support Emdeon’s structured standardized messaging.

At the same time we advise payers in a similar way that we will accept the 5010 TA1 in response to an 837 claim file sent from Emdeon. We’ll also accept either the 999 or the 997, again, based on the payer’s preference. We will accept the following claim level status responses to an 837 5010 file and those include the 277CA, as well as the 277U, which is the unsolicited request for additional information, and the 277 Pending Status. And we also will continue to support the Emdeon claim status overlay, CSO format, payer proprietary claim status reporting and all existing X12 acknowledgement transaction versions. So there’s additional guidance there but the point is we try to be very specific about what we do accept and we do offer some option for both payers and submitters in terms of what particular acknowledgements they want to receive.

As the Subcommittee evaluates recommendations on development and implementation of standards for acknowledgements, we encourage you as has been recommended by others this morning to consider the importance of education and outreach to help stakeholders really understand the benefits and the effective use of all of these transactions.

Of all the things that we want to focus on this morning, I think in particular we want to focus on how important it is to distinguish between syntax and content within these transactions. Emdeon continues to work to foster adoption and best practices in the use of acknowledgements among our customer base and we understand that provider billing systems can range from very simple software packages used to create an electronic claim to complex, integrated hospital systems. In many instances the provider’s billing clerk may be unaware of all of the infrastructure in place behind the scenes to generate that electronic file.

When there are problems in the structure of the file or the syntax, the provider must notify the software vendor or their internal programming staff or IT department. Conversely, when there are content problems such as within a specific claim in the transaction file, software vendor or the programmer cannot fix the problem and must rely on the billing clerk or the provider to resolve the problem.

Thus a premier consideration for best practices and acknowledgements is clearly defining the difference between syntax issues and content issues. Syntax issues can relate to programming, structure or the validity of a transaction set, meaning the file or the envelope. Content issues relate to information required in a claim or other unit of work within a transaction set. A transaction set often contains multiple claims or units of work. Thus, acknowledgements applied at the syntax level affect all the units of work within the transaction while acknowledgements applied at a content level impact only the unit or units of work that contain the errors, not the entire set.

Emdeon’s goal with the clearinghouse is always to apply acknowledgements in a manner that corrects the problem as quickly as possible with minimal disruption to individual units of work. To accomplish this goal, Emdeon has deployed the 999 for X12 syntax only. A 999 error transaction causes all the claims within the transaction to be rejected. To avoid rejecting claims unnecessarily Emdeon has elected not to use the 999 for missing information or incorrect use of content, which are in fact implementation guide or business rules.

For implementation guide and other content issues Emdeon prefers to reject within the validation system where it is possible to address claims individually using the 277CA. And I would like to provide an example of that. So as an example, if a batch contains a claim that has an invalid Social Security number, meaning that it begins with a set of numbers, the rule is that they can’t begin with numbers between 800 and 999. If it contains an invalid number, and the 999 response comes back that the entire batch is rejected, and in fact it should have been rejected using a single – as a single claim using the 277CA. And in fact we actually looked again to verify that the implementation guide for the 999 actually states specifically that the 999 should not be used for application level errors. So again, we just think it’s really important to make that distinction.

Our provider customers have told us that they prefer to see errors reported at the same time in order to avoid delays in final payment or denial of claims. Where possible it is best to distinguish between programming errors or syntax errors and those that are data entry and content errors because the action to correct them is different. As one of the largest healthcare information networks in the country it’s vital to us and our customers to know as quickly as possible which errors are ours to correct and which errors need to be referred to the provider, i.e., content errors, for correction.

In order for us to make this important distinction we need a meaningful and actionable response at the claims level. We cannot get this level of detail from a 999, so we use the 277CA to address all content-related and claim level issues.

To better illustrate the differences between the different types of acknowledgements we’ve prepared a set of use cases to show how they’re applied at each stage of the EDI process. The following sample workflow will show each of the major stages in the EDI process and demonstrate how acknowledgements would be applied to a very common set of use cases. And I would just point out that these particular use cases were presented in a similar form to the WEDI acknowledgement workgroup in the past as a part of an educational presentation.

So if we look first at really the initial file submission, which is really at the interchange stage of the EDI process —

DR. SUAREZ: Susanne, I’m sorry to interrupt you. We probably need to wrap up very quickly to the other testifiers.

MS. POWELL: Okay, all right, then I will move past then, again, the use cases are there and you can certainly review those in detail and I think they do provide examples of where and how we would apply the different transactions. And I would just conclude by offering the following recommendations to the Subcommittee for your consideration. First of all, requiring consistent use and acceptance by stakeholders of the TA1, the 999 and the 277CA acknowledgement transactions as outlined above, with the TA1 and the 999 being used to address syntax issues and the 277CA used to address content issues including implementation guide, front end edits, business rules and benefit determination issues. Secondly, to ensure use of consistent formats and data sets for each standardized, acknowledged transaction. Third, to incorporate appropriate education and outreach into the implementation timeline, and finally, to continue work on reason and remarks codes related to claim status that will directly impact the quality of these acknowledgement transactions.

Again, we appreciate your time and attention and Debbie and I would be happy to answer questions at the appropriate time or provide any additional information that you might need. Thank you very much.

DR. SUAREZ: Thank you so much, Susanne, thank you. We’re going to go to Doug.

MR. BILBREY: Good morning and thank you. I’m Bill Bilbrey. I’m from the SSI Group. I’m also representing today the Cooperative Exchange and HBMA. I’m honored to be here. This is really the Who’s Who of healthcare EDI and I’m honored to be part of this panel this morning. I will say that my presentation is a summary of the testimony that has been submitted so I’m just going to hit on some of the high points in the interest of time. And I want to start by saying acknowledgements – I want to address that in the broader context of acknowledgements, which will reinforce some of the things Lisa and Gwen said earlier.

And I’ll start with the 997, 999 and I guess the 277CA is not the problem, and I’ll dive into that further. Some background information on the acknowledgement transaction, and it was interesting because several other folks here this morning have referenced the 4010 conversion, that when that conversion took place, while there were standards there was not mandates that those standards would be implemented. Therefore there was a major drop off in reporting capabilities that resulted, with the introduction of the 4010 standards – loss of proprietary reporting, lack off adoption of the 276, 277 which is the real time transaction.

And actually for some time there, there was – I think it was Lisa that said the clearinghouses did not know how to use the 997. That’s absolutely correct, but we wondered real quickly how to take that 997 and at least give the providers some assurance that the claim had actually gotten somewhere. It didn’t necessarily say the claim was being processed, which is the bigger picture.

I would say as it stands right now, 2011 status, that would be today, is compared to where we were pre-4010, in some cases it’s not as good. That is ridiculous because what the clearinghouses had done pre-4010 as we had written, some degree of standardization with the proprietary formats. I know that’s an oxymoron but we took the proprietary data and transformed that into information that the providers could make informed decisions on.

Holistically, the perspective of acknowledgements in this presentation, I’m going to address it from a standpoint of the benefit transaction, claims status and treatment authorization. Some of the challenges and the impacts of these challenges, is the clearinghouse tracking number which in some cases does not pour from the claim to the claim status to the remit, as well as from the real time benefit transaction. So while we are able to process as clearinghouses 997’s, 277CA’s, and solicited 277’s, without that clearinghouse tracking number or trace number it’s often difficult, especially when you have where you’re passing a file from one clearinghouse to the other where you lose track of who has the claim, where is it, where does it really stand.

There is a lack of detailed accountability on submitted claims. The 997 really doesn’t do a whole lot for a provider other than tell them the claim got into the payer or plan. It doesn’t give a disposition as to what’s happening with that claim. So that creates a lot of manual follow-up where payers don’t support real time claim status.

Another big impact is that in some cases even after a positive acknowledgement, like through a 997 or even on a solicited 276, 277, or claims status transaction, significant changes in the disposition will happen without any notification to the provider. So then they’re left waiting for timetables to expire or the remittance to come in with the denial.

Manual processes for claim acknowledgement such a telephonic websites, they have significant limitations, mainly, most plans that will support a telephonic inquiry to determine a claim status will limit that to a handful of claims, two or three.

So you have larger operations – billing companies that are the primary members of HBMA, large outpatient centers, hospitals, etc., that will have staff that strictly queues up, “Okay, I’m going to call the payer, I’m going to hold, and I’m going to check on these four claims, and I’m going to call them again. The payer has the same thing happening on their end, so it’s not real effective and it certainly doesn’t give us the opportunity as vendors to employ some of the technology we have that would automate these processes.

In January SSI had the opportunity to participate in a data gathering survey with CMS, and part of the survey, the survey focused on really the operating rules and the national health plan identifier, but there were questions in the survey related to, of your health plan customers, how many have adopted the real time claims status? In SSI’s case, it was only two percent. We support about 1,500 health plans, so to me that is a very low ratio of health plans that are actually supporting that transaction. Twenty-two percent of the health plan customers support real time eligibility.

I will underscore both of those statistics are non-Medicare, and that’s what the survey was intended to identify, was anything non-Medicare. When we looked at it from the provider standpoint, 20 percent of the provider customers of SSI are using the real-time eligibility transaction, and only five percent are using real-time claim status. So you can see that proportionally those two numbers kind of match up from both the plan and the provider standpoint.

And from a treatment authorization standpoint, that transaction is so minimally utilized – less than one percent – there’s just a handful of payers that I know of that support it, so it’s really almost a non-transaction. I will underscore that our colleagues back here from Aetna and United, I’d reinforce Bob’s point. They are the cream of the crop. They do good with all of these things here. But that’s not the norm.

Now the way we’re getting around there, there’s some workarounds. Many of the vendors have developed screen scrape interfaces. These are primarily adopted for Medicare, and they work pretty well other than they can be manual labor intensive because you have to watch these interfaces. If they fail, they can get behind. So they’re automating some of the claim status processes. They’re alerting the providers too, ADR’s, additional information, return to provider. And so based on the systems that are out there that we as vendors had developed, we can equip providers with tools to make informed, proactive decisions based on that feedback.

Some vendors SSI does not do, so some of the vendors on the cooperative exchange had developed interfaces. A few payer websites that essentially work like Medicare clearinghouses will host eligibility and claim status databases. My testimony indicates that that’s a pretty effective workaround solution but not adopted by many plans. And I can speak for SSI, we only have a handful that actually do that, and what they do is they send us their claims status database, we host it and we facilitate real time reporting back to the providers.

Workflow-driven solutions is another workaround, and that goes back to another point Lisa made earlier where we know as an industry that if I send a claim to XYZ payer that if I don’t get the 997, obviously that’s a red flag. If I get the 997 telling me there’s something wrong, that’s an obvious red flag, and things happen. But we can also take it further than that for those payers that support real time. We can say that after X amount of time, if something hasn’t happened, like it hasn’t moved from step one to step two, and that creates a red flag or set parameters to govern, do the solicited statuses as it makes sense to drive the workload to the provider so they’re not wasting time.

And I think it was the gentleman from WEDI that made the point about the exception. The providers only want to work on exceptions. They don’t need to waste time worrying about claims that are just flowing through the adjudication process. Payer websites is another workaround, and while that is from a payer perspective that’s probably – they deem that to be okay. It’s very labor intensive and it’s better than telephonic, but it does require a lot of manual work from the providers to go look at those websites.

And another side point is that often those websites do not provide the same information that you get through a real-time transaction, so that creates ambiguity and it challenges – I think the gentlemen from WEDI said this as well – the faith in the transaction is compromised because it’s not consistent with what you get real time. And I’ve already hit on telephonics. I’ll skip over that.

In regards to operating rules, Phase I and Phase II have provided positive outcomes. I can say that SSI was kind of reluctant to go down that path initially just because the amount of work that was contemplated, but it was a very favorable outcome and that once we completed the implementation of Phase I and Phase II we found that we had improved operations, reduced costs and a better overall product. We’re now able for those payers that do support and abide by the CORE operating rules, let’s just say a payer that’s going to bring up real time eligibility, we can bring those guys up much quicker because we’re all kind of operating under the same guidelines and it makes the delivery timetable much faster.

But I will underscore here, and actually Gwen presented at the cooperative exchange meeting at HEMS in February, that while the rules are awesome the benefits are limited to those plans that choose to abide by them, and so in other words if a plan just said well I’m just not going to do real-time claims status or I’m not going to do real-time benefit verification, they don’t have to abide by the rules so therefore they’re not in noncompliance, they’re just not doing it.

Notable mention here at X12 and CORE, X12 from our perspective at SSI and the Cooperative Exchange, it’s doing a great job with setting of standards, and CORE does a good job, a great job in telling us how to use those standards. Recommendations – eligibility treatment authorization and claims status should be considered, acknowledgment transactions, I think that’s been stated multiple times today. I’m just saying it a different way, but again the 997, 999 from a clearinghouse perspective is not the problem. It’s that we can’t get down to that level of detail that equips the providers to be more proactive.

Operating rules should require that a payer or plan support all of the X12 healthcare transactions. That would be from the benefit transaction, the treatment authorization, obviously the claim, which is pretty widely adopted, remits and claims status.

Clearinghouse trace number should be available on all healthcare transactions, and there should be rules, of course, to govern how that trace number is shared amongst clearinghouse to clearinghouse connections, and positive acknowledgements should be available on all claims submitted, no assumptions. So the provider should never have to sit there wondering what’s going on with the claim. There should be positive acknowledgement as to the disposition on that claim, and if a claim is altered post-acknowledgement, there must be a 277CA sent back to that provider so they can know they need to do something with that claim. They’re not just happily waiting for that payment only to find out two or three weeks later that it’s not coming.

Conclusions – again, the 997 is being used and works as prescribed. We believe the 999, once 5010 goes into effect, will improve the file level acknowledgement process and should help with some of the clearinghouse to clearinghouse connectivity. Significant improvements could be attained through the total adoption of X12 healthcare transactions and I will be happy to try to put some quantitative information available for you guys on what we think those costs would be from both the provider and plan perspective, just in the FTE considerations. A timely adjudication process, and lastly, EDI or clearinghouse companies have the solutions in place. I can assure you that providers that SSI has as customers as well as those that are members of the cooperative exchange, the providers are more than willing to use these solutions. They just need more plans to participate in it. And that’s it. Thank you.

DR. SUAREZ: Thank you very much. John?

MR. KELLY: Lisa Miller, this morning, I think made an important distinction. John Kelly, CIO at NaviNet. We’re a vendor in the HIT space that does transactions through portals, gateways. We do both clinical and administrative on hand-held devices, portals, and also machine to machine.

This morning in response to a question Lisa I think made a really important distinction when she mentioned that you have to look at these transactions from the point of view of there’s a technical component and there’s a business component. I’d like to spin that a little bit and say there’s a machine component and there’s the human factor component, and that a lot of, each of the transactions depending on how they’re used, whether they’re real time, whether they’re batch, whether it’s machine to machine or whether there’s humans in front of a portal, it’s important to bear in mind when you think about how acknowledgements need to be used.

So I’m going to take a couple of minutes and spin this from a human perspective. Please, thank you, thank you, you’re welcome. These are acknowledgements. They’re as natural to humans as breathing in and breathing out. And it’s interesting to be here talking about acknowledgements and debating their role and form with respect to electronic communication. One might assume that given the role of acknowledgements in other forms of communication they are considered essential. I suspect somewhere deep in an analysis of Maslow’s hierarchy you’d find that we all have a fundamental need to be and feel acknowledged.

So what’s behind us being here today to consider the utility of and the requirements for electronic acknowledgements? I’m sure everyone in the room on more than one occasion has had the experience of being deep in a conversation with someone on their cell phone when you suddenly have an uncomfortable sense of silence from the other end of the connection. You know you’ve just had a fleeting moment of brilliance, you’ll never be able to capture that thought again which you expressed so eloquently, you freeze, and you utter the words, “Are you still there?”

We’re so used to the phenomenon of dropping a call that we are constantly doing subconscious monitoring of our wireless connection. Imagine, though, that the connection was still good, the person on the other end of the line heard every word you said, but in defiance of common decency they sit silent in response to your request for acknowledgement. What would you do? Would you assume the call was lost? Maybe they were on mute while multitasking. Would you take the phone from your ear and check the display for some indication from the hardware that your words were lost? Would you just keep repeating, “Can you hear me now?”

No, you wouldn’t. We have a cultural convention that compels us to respond that we are still on the other end of the electronic connection. We’re obliged by the rules of acceptable behavior to confirm our receipt of the message in order to optimize the utility of human conversation. And on the contrary, the specific lack of any sound from the phone speaker is confirmation in itself that the message was not received. So to push the metaphor a little further, what if the call was lost and now the other person is in a dead zone. When did they lose the call? Did they hear your whole thought? Part of it? None of it? What if you needed them to take action, which if they didn’t there would be dire consequences?

Wouldn’t it be important to know exactly when the call got dropped? Wouldn’t your course of action in response to the dropped call depend entirely on whether you could or not ascertain exactly at what point the communication was interrupted?

Try another use case. April 15th was not long ago, and does anybody doubt the value of receipts if you get audited by the IRS? Every important financial transaction we do in our lives is completed with an acknowledgment of exchange, a tangible, persistent evidence that the exchange did indeed take place. And further, there are rules as to what constitutes evidence of a transaction and what doesn’t. An image of a bank check? Yes. A note on a napkin from your brother living in your mom’s basement? No.

Not only an acknowledgement is crucial, but a consensus of all the parties involved as to the form and substance of the acknowledgement is required in order to survive an audit. There’s a theory of communication that came out of the Stanford Computer Sciences Lab back in the early 1980s. And they posited that all human conversation could be distilled into a series of requests and promises, a continuous dance, if you will, with each round confirmed with the completion of a promise and a new request and response. When a promise is not completed, the communication loop ceases to function, and applied to interactions between humans and computers, this communication theory is foundational to much of the research and development that created today’s thinking machines.

Without machines shaking hands, nothing gets dependably automated. And I do believe that what’s behind us all being here today is that Healthcare System desperately needs things that are dependably automated. The corollary to this point, to the points highlighted by my anecdotal metaphors, is that the application of acknowledgements and handshakes, to machine to machine processing, needs to be practicable. The principle of utility dictates that we shouldn’t interrupt our phone conversations every 15 seconds to verify connectivity, nor should we keep receipts for every penny we spend in the course of our day-to-day affairs. Likewise, standards and operating rules for electronic acknowledgements need to be crafted within the context of business utility. A simple “yes, I’m still here” works with a phone call as opposed to a 60-second response including the time, date, location, and formal assessment of the general wellbeing of the person on the other end of the line.

From the standards perspective, the “just enough is good enough” design pattern should guide development. Experience has shown that in the 837 transaction, the 997 is probably not quite good enough, but on the other hand the 277 acknowledgement has little utility if the receiving system hasn’t had time to fully digest the transaction. The 999 would appear to be the Goldilocks of the 837 world, just right.

In addition, once the actual data elements, format and syntax of the acknowledgement transaction is defined in a standard like 999, an ongoing system of formal governance needs to be in place to achieve consensus among the process community as to the social conventions of how the standard is to be implemented among participants in order to achieve optimal utility. This commitment to consensus through governance yields a two-fold outcome: first, it ensures that the constituents agree to make the appropriate capital investments in infrastructure to sufficiently engage in an optimized communal process; second, it provides feedback to the standards development organization to seed the next round of revisions to the standard.

So in summary, and with regard to the healthcare system desperately needing things dependably automated, I suggest to the Committee that the most valuable contribution you can make is to drive this two-fold outcome. In far too many meetings and conference calls I participated in over the past five years I’ve observed the lack of commitment to infrastructure investment is the single biggest obstacle to achieving significant gains in administrative simplification.

Too many entities are comfortable taking the “it’s too hard, it’s too expensive” position. There have to be table stakes to play in the marketplace. There has to be reward and incentive for those who make strategic investments in process and technology improvements, and there have to be market penalties for members of the community who generate economic externalities as a result of trying to squeeze the last ounce of profit from aging systems.

Mandated operating rules for all of the transactions drive innovation and efficiency by nudging investment. The byproduct of the investment is that new technology will be designed to assume shorter cycle times for standard revisions, and thus the standards organization will be far better positioned to incorporate feedback from the operating rules and to a streamlined and regular revision cycle around which the process community can dependably plan. I want to thank the Committee for the opportunity to talk today and to offer testimony, and I welcome any questions. Thank you.

DR. SUAREZ: Thanks so much for that testimony. We’re going to go last here to Shelagh, who is joining us by phone. Shelagh, are you there?

MS. KALLAND: Yes, I’m here Walter, thank you.

DR. SUAREZ: Thank you. We can hear you perfectly.

MS. KALLAND: I do want to assure the Committee I realize that time is ticking away and my testimony is rather short, so if you just are patient for a few moments we’ll be to the questions. Co-Chairs and members of the Subcommittee, I’m Sheila Kalland and I’m speaking today on behalf of the Minnesota Administrative Uniformity Committee, known as our AUC, and as Co-Chair of its Acknowledgements Technical Advisory Group. I’d like to thank you for the opportunity to present testimony today concerning the provider payer and general industry perspective of acknowledgment.

Just to tell you a little bit about us, the AUC is a voluntary stakeholder advisory organization with balanced representation between payers and providers. It served for nearly 20 years to achieve consensus between payers and providers in Minnesota on standardizing healthcare administrative processes to reduce administrative cost burdens. The AUC is comprised of healthcare providers payers, which include medical, workers compensation, property and casualty and auto, state agencies and healthcare associations. Our membership includes the Minnesota Department of Labor and Industry as a representative of non-HIPAA covered entities.

The AUC receives staffing and logistical support from the Minnesota Department of Health and has no dues or membership fees. All AUC meetings and activities are well-publicized in advance and are open to anyone wishing to attend. Remote access through dial-in and webinar capabilities is provided. The AUC actively pursues input from other organizations including clearinghouses and vendors in developing our solution.

The AUC has developed and implemented state-wide companion guides for several of the HIPAA transactions including eligibility, claims, and remittances. In addition the AUC has developed single, uniform companion guides for three types of healthcare acknowledgements: the TA1, the 999 and the 277CA, pursuant to recent amendments of Minnesota Statutes Section 62J.536. An overarching principle of the work of the AUC is the fact that all parties affected by the statute may be required to make changes to procedures, policies and/or systems in some way as a result of the work of the AUC, resulting in lowering or slowing the rise in administrative costs for the system as a whole.

Minnesota session law in 2010, Chapter 43, Senate file number 2852, requires the AUC to develop Minnesota Uniform Companion Guides for acknowledgement transaction. This law requires all healthcare providers, healthcare clearinghouses, and group purchasers to provide an appropriate standard electronic acknowledgement when receiving the healthcare claims or equivalent encounter information transaction, or the healthcare payment and remittance advice transaction. The acknowledgement provided must be based on one or more of the following ANSI-accredited Standards Committee X12 transactions – the TA1, the 997, the 999, or the 277CA.

Please note that the Minnesota mandate does not require all acknowledgements be used at the same time for a singular transaction. With each acknowledgement comes the cost to transmit as well as to process at the receiver site. Our recommendation attempts to minimize cost while maximizing business benefits. I will address this further in a moment.

The effective date of the Minnesota mandate is January 1st, 2012, to coincide with the implementation date for Version 5010 of the HIPAA transaction. The AUC has completed, vetted and published the companion guides for the acknowledgement transaction of TA1, 999, and 277CA. As with our other mandated transactions, the AUC reviewed the Medicare guidelines and modified them only when the community believed necessary to achieve maximum administrative benefits.

The AUC further proposed that the Department of Health not adopt the functional acknowledgement 997 based on formal interpretations that were conducted by ASC X12. The interpretation states that for healthcare TR3 implementation the 999 transaction must be used.

Further, the AUC acknowledgement TAG is completing a best practice which includes process flow diagrams, suggesting how the set of acknowledgement transactions are used together to provide clear responses to the sender of the transaction. A sample of the process flow diagram is attached to the presentation in its written form and I believe is available there for you to bring up on the web-x as well. And if you click through it you will see that there’s actually a sequence of events that occurs, so if you could click through that all the arrows start to appear. And you can click through it about 10 times for all of them to appear. You can just bring them all up. But we did want to illustrate that it is an iterative process between each of the parties involved in the transaction exchanges. There’s four more. Perhaps it didn’t all go through, so we’ll make sure that you have that.

The AUC acknowledgement TAG has identified three differences in the way that we’ve proposed implementing the acknowledgement transactions in comparison to the CMS interpretation, and I’m going to walk you through those three differences now. The first difference is that the AUC recommends that a TA1 be sent only in the event of failure of the interchange. Although the transaction envelope allows for the sender to indicate that they wish to receive a TA1, we recognize that receipt of multiple acknowledgements becomes an administrative burden. As a result it is our recommendation that the TA1 not e requested specifically by the sender, but that it is sent only in the event of an interchange error.

The second difference in our recommendation relates to the use of the implementation acknowledgement or 999. CMS has indicated in their presentation that providers will receive a 999 accepted with errors. The AUC recommends that the 999 be used to indicate that the transactions that have been accepted or rejected in its entirety for further processing.

The AUC further recommends that the 277CA be sent to provide transaction level information related to acceptance or rejection. Sending the 999 indicating that the transaction that is being accepted with errors implies that the provider must do something about the errors but does not provide enough business information for action. The 277CA on the other hand will provide specific information related to the rejection, such that the provider can take action to correct and resubmit the claim.

The final difference is related to the work that the AUC completed to define and map claim status and claim category codes to standardize the results that will be received by the providers across payers. It appears that not all claim status and claim category codes were intended for use in the claim acknowledgement 277CA, and those not intended for use were removed from the Minnesota Uniform Companion Guide list of allowed category codes.

Further, through the use of a mapping table, we’ve developed a solution that provides consistency of use within the national standards that enables providers to take appropriate action to correct errors and resubmit transactions for adjudication. Inconsistency in the use of claim status and claim category codes requires providers to alter posting programs for each payer’s 277CA file. Nonstandard use of the claim status and claim category codes invokes phone calls to the payers, driving up resource costs and wasting both provider and payer staff time.

The AUC recommends that the industry pilot these transactions before CMS requires them under a HIPAA mandate. Over the years, WEDI and other testifiers have stated that mandating transactions that are not tested and proven does not result in adoption or in reduced administrative costs or burden.

We offer that two of the pilots could be the Medicare implementation and the Minnesota implementation, along with any other established community pilot deemed ready by January 1st, 2012. The pilots will provide feedback to NCVHS and to the Operating Rules Standards Committee chosen to develop national operating rules for acknowledgement. The pilot should have members benchmark their current processes and costs so that savings and reduced burden can be measured. In addition, the pilot participants should report on specifics of each acknowledgement transaction including data content and technology issues such as connectivity or response times or transaction flows.

In conclusion, the AUC strongly supports standard acknowledgements as an important part of administrative simplification, and we would be happy to report on our experience. Again, I’d like to thank you for the opportunity to testify today.

DR. SUAREZ: Thanks so much, Shelagh. I appreciate the testimony. We have about – well we are a little over time here but we do want to take a few minutes to ask questions. We’ll adjust the time for lunch and for the breaks. Do we have any questions from any of the Committee members at this point? Judy?

DR. WARREN: I had a short chat with Walter at the break, that it’s an observation that I’ve been having for some time, especially as we’ve been going through these different standards. And so what I’d like to do is get a feel for people that are present this morning on what you think of my idea. Practically every one of you has made a comment somewhere that software vendors do not know about a transaction, cannot handle a transaction, and/or don’t support some of these transactions. So I’m wondering if we shouldn’t take a letter from ONC and take a look at possibly certifying the practice management systems much of the way we’re doing now with the EHR’s. (Applause) X12 is easy, so…

SUAREZ: That sounded like a very positive acknowledgement. (referring to applause)

DR. WARREN: Which you need to add in your paper, John.

MR. KELLY(?): Can I make one question about this morning, because this notion of the FedEx metaphor – I’ve been using it almost 10 years and I thought I’d wrung every last bit out of it, but the one thing that didn’t get mentioned on this overload thing is, think of how many times when someone checks off that little box “signature required” what a pain in the butt it is that you have to go through to go to the post office and coordinate your schedule with theirs when that signature is required, and then also think about how FedEx has their own kind of fuzzy guidelines about if it’s not checked off, whether they leave the package. Is it valuable? They probably require a signature. If it’s a high crime neighborhood they probably will require a signature. If it’s a single family home and there’s a lot of space around, they probably leave the package on their own. So even though FedEx does track, there’s still that last mile of connectivity allows a little bit of flexibility for the specific use case of what’s in the package and where they’re delivering it. So I’d just like to throw that out. I don’t think it’s so much a question of overload or not. I think it’s more a question of context of usage of a particular transaction.

Agenda Item: Questions by the Subcommittee

DR. SUAREZ: Thank you, thanks. So I’m going to try to wrap up this morning’s session. First of all, again, thank you all of the testifiers for your testimony. Very, very valuable. I think this has been a really terrific morning, and I think generally what we have heard if I’m correct is that first of all there is a clear sense that acknowledgements are a valuable piece of information in the EDI transactions. There seems to be no question about the type of acknowledgement that we need to look into, the TA1, the 999, the 277CA. There seems to be no question about the standards themselves, either.

It’s more a question, not about whether but how quickly can this be put into place, and there are some questions certainly about a number of things like what triggers an acknowledgement, when should an acknowledgement be really expected, when shouldn’t it be. There’s clear differences between real-time and batch transactions and how the acknowledgement would work there. There’s some questions about versioning, not so much questions but the concept that certainly a 5010 version will be expected minimum, that there is also support and consistency in terms of the later versions of the acknowledgement with respect to 5010, for example, so there’s that capability of the transaction.

There seems to be some question of course about some specifics, like the 835 particularly, and some concerns about when and to what extent the 835’s should have an acknowledgement. Pharmacy transactions seem to be another area where there are some differences in terms of applicability of acknowledgements. And there’s also some points about the transition and the phasing of this acknowledgement process. And then finally of course there’s the issue of cost, how much will this cost at the end to the industry. There’s been a lot of talk about the benefits and a lot of highlights of the benefits, but we would want to get some more information about the costs.

So I think those were my general elements. I know there’s a lot of more detail and def in the testimony provided, and certainly the Committee will go through that and begin to work through the recommendations. But I think with that, again, I want to thank all of you for attending and providing your testimony. I do want to acknowledge – to use that word – our staff for providing the support to convene this in such a relatively short notice. Thank you again to Lorraine and Denise and Michelle and all the others.

DR. WARREN: Just one other acknowledgement. I want to acknowledge Margaret for very plain speaking on the standard. That was probably one of the best presentations. And also to John, for the humor with which you addressed acknowledgements. That really helped a lot. Thank you.

DR. SUAREZ: Absolutely. Well with that, I think we’re going to reconvene. We only have about 50 minutes for lunch time, so if you could consider perhaps getting something and coming back, we certainly will be able to use this room for lunch, and we will reconvene promptly at 1:00 p.m. Thank you.

(Whereupon, a luncheon recess was taken.)

A F T E R N O O N S E S S I O N (1:00 p.m.)

Agenda Item: Part 2: Maintenance And Modification for Standards and Operating Rules

Session 2.1: Overview of Statutory and Regulatory Requirements for Maintenance and Modifications and Operating Rules, Denise Buenning, CMS

DR. WARREN: While everybody is getting their seats, I’ll just introduce the second session. One of the things that our Subcommittee has noticed since we have started working with ACA and its directives to NCVHS to acknowledge or to recommend operating rule entities and then that relationship going back to the standards transactions, is there is still an evolving understanding of what an operating rule is, what it’s relationship is, back to the SDO and things like that. So we wanted to take advantage of this time and to try to come back together to look at clarity about those relationships. I think at least I’ve got that pretty much the way Lorraine wanted me to. We were getting coached. Even though Lorraine is on vacation we’re still getting coached, so we’re going to have to work with Lorraine about what it means to take vacation, but that’s okay.

So with that, I didn’t want to spend too much time in introduction but that’s our thinking behind it, is we want to get clarity on what the SDO’s do, what the operating rule entity does, where those relationships need to grow, what each one is responsible for, and how we move the industry forward with the evolution of standards and the evolution of operating rules over time. So with that, our first panel, we are having – and Denise, did you want to make any more comments?

MS. BUENNING: Well, I think that the intent of a very brief presentation here was to discuss the statutory and regulatory requirements for maintenance and modifications to standards and operating rules, and then take the discussion forward from there. So if you want I can just very briefly go over that, just kind of level the playing field for everybody, and then we can go onto the panel. Is that okay?

DR. WARREN: Okay, my understand is that you were going to do that?

MS. BUENNING: I’m saying I’m going to do that. Okay. Thanks, Judy. Just to level the playing field for everybody, I think everybody in this room is probably very familiar with the topic, so this is just to kind of give a quick down and dirty review of the statute and subsequent regulations and where we see some of these things fleshing out. In the HIPAA statute back in 1996, and again in the final rules governing HIPAA adopted transaction, any standard adopted by the Secretary of Health and Human Services has to be developed, adopted or modified by a standards setting organization, or an SSO. And sometimes you’ll see the term SSO used interchangeably with SDO or Standards Development Organization, and we oftentimes use these terms interchangeably.

Section 1172 of the HIPAA legislation, fondly known as “The Act” describes the consultation requirements that must be met before the Secretary adopts standards, and for example in the case of a standard that’s developed, adopted and modified by an SSO/SDO, that organization must consult with certain data content committees to ensure the standard doesn’t include or exclude any requirements that are necessary for those content standards for professional, dental or institutional claims and bills.

For the HIPAA standards, these content committees are the National Uniform Billing Committee, NUBC, the National Uniform Claim Committee, NUCC, and the American Dental Association Code Content Committee. The standards organization also has to consult with WEDI, the Workgroup for Electronic Data Interchange, which is specifically cited in the law as an advisory organization with respect to HIPAA. Once these consultations are completed, the Secretary must consult with the NCVHS.

The NCVHS then makes recommendations to the Secretary, either that a certain standard of version be adopted or mandated for use by the industry. If the Secretary concurs with that recommendation a rule is published. If the Secretary takes an alternate view or alternate path from that recommendation from the NCVHS, then we have to provide rationale in our regulation as to why the recommendation was not considered or why we’re taking a divergent path. So far HHS has used the proposed and final rule process for adopting standards to ensure that the industry has adequate time and opportunities to not only weigh in on the policy but also the standards themselves that we’re adopting.

Section 1174 of the Act allows the Secretary to adopt modifications to the adopted standards after the first year, so for that first year the standards are in place and no modifications can be made. We’ve only adopted one fully updated version of the standards, excluding the additional errata for 4010. In addition to the initial set of modifications after publication of that final rule and of course you know we’ve adopted version 5010 for the X12 standards and version D.0 for NCPDP standards.

So at the same time we published the transaction’s final rule and we named certain organizations as Designated Standard Maintenance Organizations, or DSMOs. And they consist of SDO’s, which are X12 and HL7, and also NCPDP, and then we have the three content committees – the NUBC, NUCC and the ADA Dental Content Committee.

Section 162(9)(10) outlines the process for collaboration among the named DSMOs, and later you’ll hear some testifiers speak to the DSMO Memorandum of Understanding that exists for receiving, managing and processing requested changes to adopted standards. So that brings us to our present day situation, and that is a new entry into our world, things called Operating Rules. And as I think all of you are familiar with, the Affordable Care Act includes requirements for the development, review, approval and recommendation by NCVHS, but it’s silent, there’s no specific references to any kind of change, request or update processes for these tools, and we’re going to have to address this as we go forward with our regulatory work and we’re obviously eager to hear from testifiers as to how we can successfully sync up both standards and operating rules and what might be appropriate maintenance and modification processes.

So that’s just a really short overview of how things currently work, and I think we’re ready for our next segment unless anybody has any questions.

Agenda Item: Questions by the Subcommittee

DR. WARREN: Any questions from the Committee for Denise? Thank you. That was very, very helpful.

MS. BUENNING: Just a reminder of how things work.

DR. WARREN: At this point I think that’s been one of the things we’ve struggled with the most, is having to go to several sources to find out how things work and how they work back and forth with each other. So with that, we’ve designed the next couple of sessions and panels to provide more information along these processes. So we’ll start with the overview of the current process for requesting, processing and communicating change requests to standards. And so I think the first person we will be listening to is Stacey Barber from the DSMO. Stacy, are you on the phone?

MS. BARBER: I am.

DR. WARREN: Okay, whenever you’re ready.

Agenda Item: Section 2.2: Overview of Current Process for Requesting, Processing and Communicating Change Requests to Standards, Stacey Barber, DSMO (via phone), Margaret Weiker, X12, Lynne Gilbertson, NCPDP, John Quinn HL7

MS. BARBER: Good afternoon, everyone. I’m Stacey Barber. I’m the current Chair of the DSMO, and I am the primary rep from ASC X12, representing X12 on the DSMO. The members of the DSMO thank the NCVHS Subcommittee on Standards for inviting input on the review of current industry processes for requesting, processing and communicating change requests and ID of process improvements.

Since the formation of the DSMO, the individual DSMOs and the DSMO Steering Committee have worked closely with NCVHS and its subcommittee. While most of the membership of the subcommittee is aware of the DSMO’s history and process, we would like to use this opportunity to provide a brief outline to establish a base understanding for those here today and for others in the healthcare industry. As Denise mentioned earlier, the DSMO formed through their final rule and notice titled “Health Insurance Reform: Standards for Electronic Transactions” announcement of the Designated Standards Maintenance Organizations published August 17th of 2000. A separate announcement published on the same day named the six organizations that made up the DSMO. It was mentioned earlier, ASC X12, Dental Content Committee, HL7, NCPDP, NUBC (voice drops out). X12 HL7, NCPDP are all Standards Development Organizations; and DCC, NUBC and NUCC (voice drops out)

The regulatory language in the final rule established a framework for the DSMO and the maintenance process as follows. The Secretary may designate as a DSMO an organization that agrees to conduct the following functions: Maintain standards adopted under HIPAA; receive and process requests for adopting new standards, or modifying an adopted standard; maintenance of standards by the appropriate DSMO constituent maintenance of the standard – constitutes maintenance of the standard. The Secretary will consider a recommendation for proposed modifications to an existing standard or a new standard only if the recommendation is developed through the process that provides for open public access, coordination with individual DSMOs, an appeal process, expedited process to address content means identified, and submission of those recommendations to NCVHS. The six DSMOs entered into a Memorandum of Understanding and following this announcement established the DSMO Steering Committee and protocol for operations.

Officially the Committee is made up of one voting representative and one alternate from each of the representative DSMOs. Each organization has one vote. A representative from the Department of Health and Human Services serves in a non-voting liaison role.

The current process operates under a practice that includes the following guiding principles: Allow for open public access; provide for timely review; operate and communicate; consider all viewpoints; evaluate the impact of each change request; maintain a national perspective; and conform to law. The DSMO established a website to manage change requests system and establish a process for submission of requests, review by the DSMO, notification to the requester, and appeal process if necessary. The DSMO also established yearly reporting to the NCVHS on maintenance completed in the previous year and recommendations of next regulatory actions to the industry.

I don’t know if you all have the flow charts that we put together, but that’s pretty much depicted on this, the Current Process on the current one that’s being shown now, and moving forward into the next couple of slides going forward, bringing in potential operating rules into the process.

So in the assessment of the current process, since the inception of the DSMO, the DSMO established a proven framework for review and maintenance of HIPAA-mandated standards. Initially the focus was to incorporate modifications to the original HIPAA-mandated transaction standards beginning with a fast track effort resulting in the ASC X12 version 00 4010A1, and NCPDP telecommunications standard version 5.1 and batch standard version 1.2.

Once the fast track review was completed, the DSMO was able to turn its attention to other changes that have been or will be incorporated into future versions of the transaction standards. Hundreds of change requests have been processed through the DSMO process since the completion of the fast track review. While the industry is familiar with the process we do believe that modifications to the current process timeline, as well as updates to both DSMO websites and potentially individual organizational websites and the industry as we move forward into the future. The DSMO believes that these proposed modifications will align with the Patient Protection and Affordability Care Act recommendations to establish an expedited process for introducing new HIPAA-mandated standards.

The monthly average of change requests both received and completed has decreased significantly in more recent years, which could be attributed to the versions being in place for several years and any immediate changes had already been addressed. A second potential cause of the DSMO change requests is the shift in requesting submitted directly to the SDOs as more of the industry has become involved directly with the (voice drops out).

The SDOs track changes made by – based on a DSMO change request. They also produce a summary of all changes made to respective implementation guides, which is included in their final work product. As newer versions of HIPAA-adopted implementation guides are brought forward, DSMO continues to pay specific attention to those changes in the guides that did not come through the DSMO approval process.

The DSMO would like to note that there have been increases in change requests over the last three months, most likely due to the announcement by ASC X12 that any changes for the next version of ASC X12 TR3’s needed to be submitted by February 4, 2011. Those requests are currently under review according to schedule and when they were submitted. It is anticipated that the change requests will return to a lower volume, highlighted above, until the next SDO development cycle.

Moving on into recommendations for process improvements, DSMO would like to offer recommendations for establishment of a process that can foster collaboration and coordination between the DSMO and the new — entities charged with developing – the development of operating rules. It is vitally important that the entities responsible for developing operating rules coordinate with the DSMO to ensure that the industry recommendations for modification and implementation timelines are consistent with the HIPAA-mandated transaction standards.

Coordination is also needed to help identify changes to future HIPAA-mandated guides and to ensure that any operating rule criteria being developed are supported by the applicable standard and are consistent in interpretation.

Additionally, ACA seeks to establish an expedited process for introducing new HIPAA-mandated standards. This too will require coordination with the DSMO as new standards and underlying operating rules are being contemplated for those standards requiring operating rules.

The DSMO recommends a framework for coordination and collaboration as follows: Entities responsible for the creation of operating rules for each of the transactions must adhere to the consistency and conformity of the standards. Operating rule entities membership must represent expertise in the standards, demonstrate balance of representation, openness in consensus, with all industry parties in their process. Operating rules entities develop and maintain an approved process for updating the operating rules. This can be accomplished by requiring the entity or entities to become accredited by ANSI. If multiple entities are selected and there is an overlap with the HIPAA-named transactions, expertise collaboration must take place with the (voice drops out) for a single set of operating rules for that specific HIPAA-mandated transaction. The industry cannot effectively support multiple operating rules versus a single, HIPAA-named transaction providing the same industry function.

The operating rule entity or entities must work closely with the HIPAA SDOs and ASC X12, HL7 and NCPDP as new standards or versions of standards are being developed. As industry requirements are brought forward, updates need to be evaluated as to their appropriateness in the implementation specification or in the operating rules. Guidance, for example, data content rules would be brought forward to the appropriate SDO for consideration of inclusion in the implementation specification.

If you can back up a little bit to page four, this that we’re talking about right now is kind of illustrated and flowed on that page. The updates for the operating rules must be in coordination with the implementation specification reference and the schedule for operating rule updates must be coordinated with updates through the implementation specification versions in the regulatory process when appropriate. The recommendations for operating rules updates must come through the DSMO, NCVHS and HHS process.

The DSMO recognizes that the deadline for ACA requires adoption of operating rules to the standards already adopted. As such, the DSMO is suggesting these recommendations as a starting framework. All operating rules must comply with the HIPAA regulatory language. The DSMO is reviewing processes to see where streamlining can occur. Coordination by the operating rule entity or entities with the DSMO must be completed for adoption of a rule to existing or new HIPAA-mandated standards utilizing DSMO review and approval process.

A formal regulatory framework for handling the introduction of new operating rules, other transaction standards, existing and future versions, must include coordination and collaboration with the DSMO prior to the rules brought forward to the NCVHS. Coordination between the DSMO, the SDOs and the operating rule entity or entities is vital to provide the industry with a consistent and timely process for updates to the HIPAA-mandated transaction standards and the accompanying operating rules.

Items that were taken into consideration by the DSMO in making these recommendations were organizations pulled from the same pool of volunteers of industry expertise, and this expertise must be used in an effective manner. Implementation specifications adopted are already subject to modification adoption via the interim final rule comment process. Approved changes – approved will appear in the implementation specifications during the next cycle – requirements, guidance, etc. on to the implementation specification. Operating rules must address issues outside the scope of the implementation specification. If they do not fit, it may be appropriate for an operating rule.

Slides five through seven will illustrate the flow of the recommendations and topics of notice. The DSMO recommends a clear statement be issued to the industry that operating rules are not interim implementation specification rules. For example, they do not intend to fix the implementation specification, add additional requirements to a transaction, or provide a stopgap until the next version of the implementation specification is published. The DSMO recommends that it is clear that operating rules are subject to modification and adoption via the IFR process.

On slide five, it is expected that the public will not always know whether a request may be in an implementation specification or an operating rule document. The public may submit a request to the incorrect entity. In that event, the DSMO recommends that the entity will forward these requests to the correct reviewing entity, and inform the submitter of this action.

The DSMO recommends that the request should be sent to the DSMO or the FDO first, unless it is clear to the submitter that a request can go directly to an operating rule entity. The DSMO is analyzing its current website and processes for efficiencies and opportunities for improving an industry education regarding the process. DSMO recommends that the operating rule entities will have – (voice drops out) to receive public requests for modification.

The DSMO recommends any operating rule altering entities to coordinate their recommendations for operating rule version upgrades with the DSMO by submitting change requests. This recommendation will contribute to the transparent review of operating rules that should be incorporated into future HIPAA implementation standards. Recommendations for version upgrades to operating rules should follow the existing process. The DSMO submits an annual report of the change request to NCVHS, and NCVHS makes a recommendation to HHS for subsequent (voice drops out). You can move on to slide six now, page six.

Recommendations for future change request process. Change requests for a standards or operating rule will originate either from the public. Requests can go into the DSMO change request system or directly to the SDO, or to the operating rule entity. If the DSMO receives a change request after initial review, it is determined that it is only an operating rule request, it will be sent to the appropriate operating rule entity and given a newly-created DSMO category status of “sent to operating rule entity.” This allows the DSMO to be able to view, verify – be able to verify that when a new version of the operating rule document comes forward through the DSMO it did address requests received by the DSMO. The DSMO verifies today that a new version of implementation specification brought forward did address requests received by the DSMO. Or change requests will originate from the SDO and be sent to the appropriate operating rule entity. There may be requests that come into the SDO process that may be considered for operating rules. The SDO can submit an SMO change request, send request to the appropriate operating rule, or send request to the appropriate operating rule entity directly.

Another option is change requests will originate from operating rule entity and be sent to the appropriate SDO. There may be requests that come into the operating rule process that must be considered for implementation specification modifications. The operating rule entity can submit this request into the DSMO process or directly to the appropriate SDO. Once the operating rules are developed, the existing process to request naming of updated versions of new operating rules and documents must be followed. This process occurs in particular (drops out) based on the requirements outlined in ACA and used in IFR.

The process will be as follows – and this is illustrated on the next slide. Operating rule documents is requested to be named via the DSMO change requests. DSMO deliberates as usual, which includes verifying that all change requests received and approved have been addressed in the operating rule document. DSMO (drops out) recommendation to DHS, and DHS hears testimony, NCVHS notifies HHS of recommendation, HHS chooses whether to adopt recommendation. If chosen, HHS proceeds with rulemaking.

Other considerations that were taken into account is the DSMO previously submitted recommendations for a process to streamline the adoption of standards through the regulatory process. ACA has addressed concerns about the use of the Notice of Proposed Rulemaking Process, the DSMO requests that you review this proposal to see if there are additional improvements that could be made to the standards and operating rules development, to make them more efficient to the industry.

In summary, the DSMO appreciates the opportunity to participate in these hearings and present our recommendations on the current change request process and ways to improve its efficiency and effectiveness. The introduction of operating rules into the administrative requirements will be a significant change for the industry. We are pleased to see NCVHS playing a central role in the development of processes to coordinate the development of standards and operating rules. We will be happy to address any questions at this time, and the DSMO looks forward to our continued participation. Thank you.

DR. WARREN: Thank you, Stacey. Margaret, are you ready?

MS. WEIKER: I’m ready. I was born ready. I’m Margaret Weiker. I’m still with HP. I’m the Product Director there, and I’m also the Chair of ASC X12 N, which is the insurance subcommittee. Today I’m going to talk about our change request process for our standards, our implementation guides, and our reference models. X12, for those that maybe missed this morning, we’re a little over 30 years old and several hours now. We are an ANSI-accredited SDO, our standards cross industry so we have standards that are developed for healthcare, government, supply chain, that type of thing.

Today there are multiple ways to submit change request. There’s what I call a direct submission, and that is via a project proposal request; a data maintenance request; a code committee maintenance request; a DSMO request; it can come into the X12 website – we have a form there for TR3 change request; it could go directly to a workgroup; or it could be sent via e-mail or a letter or something, a paper type of document, to our Secretariat. And those are what I deemed as direct submission methods.

Indirectly there could be a comment made to a final rule or an IFR or an NPRM that the person that made the comment maybe didn’t realize, oh, in order to do that, that would require a change to the standard. So they may submit a comment to say, “eye color needs to be submitted on every transaction.” Well, and that’s good, but guess what? That would require a change to the standards. So that’s an indirect way to get something. And then we have what’s called an RFI or an HIR portal. And this is where an individual can ask a question about the standards or the TR3. And they may submit a question that they think is not directly a change. It’s how do I submit eye color on the claim. And we may look at it and say, “Oh, you can’t, but here’s a work around until it’s added to the standards.” So that’s what I call an indirect. In other words, the person’s asking something and it may require a change to the standard but they didn’t know it when they asked for it.

So project proposals. If I want to update the version of a TR3, of the implementation guide, my first step would be to create a project proposal. This must be submitted through a subcommittee, so all of any changes made to upgrade to the next version or to add a transaction or anything like that starts with a project proposal. It’s given a tracking number, it’s entered into a database, the workgroup does the work, the task group reviews it, approves it. TAS, or Technical Assessment, reviews it and they’re responsible to ensure the standard structure, semantics, all of those type of things are followed. And then we have what’s called a Procedure Review Board, or PRB. And they look to make sure that the process was followed. And depending upon what type of change it is, it may or may not go to ballot. If it’s a change to a standard or I’m going to create a new standard, that obviously would go to ballot. If it’s a change to upgrade to a version of an implementation guide, that does not go out to ballot to the X12 membership.

To make a change to the actual standard, there is the DM process and it’s a fairly simple process as you can see by the chart. Basically what happens is a user can either submit it directly to our Secretariat or can take it through a workgroup, and in many instances a person will come to a workgroup at X12 with a change request. There is a form – it’s on the website – that they fill out. It gets signed and numbered so we can track it. It’s reviewed at the subcommittee level, at the workgroup level. Depending upon what the change is, it may have to go to multiple subcommittees. If I want to make a change to the 999 transaction, that most likely would get reviewed by multiple subcommittees instead of just one subcommittee. But the bottom line is, it goes through a process. This type of change request goes out to ballot. Members and nonmembers can vote. You can comment, abstain, and then depending upon the results of the ballot there may be a need to do a recirculation ballot, depending on how many disapprovals there were. And ultimately what happens is, PRB reviews the processes and approves them. So I went through that very quickly.

Code maintenance request. X12 maintains codes. We have data elements, we have code sets, and these are internal code sets. The X12 standard has external code sets, such as HCPCS, ICD-10, NDC’s, those type of things. And we call those external code sets. We have a reference to them, but we do not maintain them. And then we have what we call internal code sets, which are code sets that are maintained by X12 and that are used in our standards. So if I want to add a code to an existing data element and it’s a simple type of code, the code source is known, it already exists, then we have a code request process.

And basically, once again, there’s a form on the website that you fill out and you submit that request. It does go out to the membership for them to comment on, a subcommittee can ask to have development work done on it to where it would go to the subcommittee to say, “Yes, we want to add eye color,” or “No, we don’t want to add eye color,” or whatever it may be. So it does go through a public comment period per se and then it gets reviewed by our procedure review board, Tech Assess, and then gets added to the standard.

Our publication schedule for our standards are fixed. It’s an unvarying schedule at this point in time. It’s done three times a year, January, March, and July, and the actual calendar, so to speak, is available on our website. So if you want to change the standard, there’s a process I very, very, very quickly outlined, and there is a schedule.

Now, if I’ve got a DSMO request, we have a workgroup that is primarily responsible for being the entry point of DSMO request, so it’s what we call workgroup 21, and the co-chairs of that workgroup are responsible for going out, opting in if it relates to an X12 change request, or if it’s, let’s say, an NCPDP change request at this point they might ask, “Should we opt in on that or not?” depending on what the change request is.

So it goes through a process to where they opt in. If it’s obvious where it needs to go, what workgroup, this is a change for an 837, then that goes to the claims workgroup, and if there’s a change to eligibility that goes to the eligibility workgroup. They assign it to that workgroup. But also what they do is, it gets routed to our change management group or our database, and there’s an administrator there, and they will go through that process, enter it in, opt in, review, come back, and it gets incorporated and then ultimately it gets reported up through the DSMO with our recommendation.

Direct submission process, again, I said the X12 website, you can enter a change request for any TR3 that we have out there. There’s a list. It’s fairly simple. We put this up when we ask for the cut-off of changes for our next version. That’s so if somebody wanted to make a change to a non-HIPAA adopted standard they could do it fairly easily. Again, this goes through a change management process. If it comes directly to our workgroup it goes through the change management process. If it comes directly to the Secretariat they review it and then assign it, as appropriate. And the reason I’m speeding up is Judy told me to.

Our change management group process, basically it comes in, it goes into a database, it’s reviewed by all of the workgroups. They can opt in, they can opt out. Obviously, if it’s a change to a claim, it goes to the 837 workgroup. But it may be to a data element that is shared amongst multiple transactions. So then the other workgroups would opt in. They would agree to the common solution. It goes through our process, it’s reviewed, added, voted on, approved, etc. So the DSMO stuff comes in here as well as any other type of change request that comes in here. This was recently implemented. It allows us to go to meet a two-year cycle to change TR3’s. It also allows us to have a one place database for any of the change requests, and we hope better quality.

Indirectly submitted, it goes to the change management group. If it’s a request for an RFI or an HIR and it ultimately is responsible for making a change to the standard, that will be so noted. If it’s an RFI that’s an official type of process that exists within our standing documents so it goes through that process as well. TR3’s and TR2’s are reference models and implementation guides. I laid out the process but it’s basically the same. We have a cut-off. The workgroup works on the draft, they finalize it, it goes through the workgroup and their voting process, it goes to the task group and their voting process, it comes to the Subcommittee, it’s put out for public comment, members and non-members can comment, those comments are worked by the workgroup, and those comments as well as the response to those comments are published and they’re publicly available. We have an informational forum which is held face to face as well as virtually. We’re – all of the comments are gone through with the appropriate response, and the reason we do this is, one, so everybody can understand why X12 said we agreed or disagreed in case we missed something. Once that’s done, the final review is done on the document, it’s approved and published.

Communications – public announcement. We do public announcements for our draft technical reports that are ready for review and comment. We have Listserves that we use, we use industry groups such as WEDI, the NMI, etc. to put out. We have these documents. They’re available. Go look and comment. Lorraine has been gracious enough to send out our recent announcements through her Listserves in Medicare and CMS, and then we also issue a press release. Anybody can comment. You don’t have to be a member. Comments are processed, posted, again, we do the forum and we do a press release that announces the publication.

The benefits of the current process. It’s open. Anybody submit a request, anybody can comment. Public, the comment and dispositions are posted so everyone knows who comments, what the comment was and what the disposition was. Timing – it’s consistent and well-documented. DSMO requests are vetted via an informed panel. Earlier we talked about the data content committees and the other SDOs that make up the DSMO so it’s via an informed panel. It’s a consensus-driven process. There are multiple entry points. While some may say that’s our problem, others may say that’s great because it allows accessibility. It’s transparent and it’s documented, it’s proven, it continues to be evaluated and improved just like any process exists today, and it works. Over 500 change requests have been submitted between the versions.

Challenges of the current process. Awareness of the mechanisms as well as what is the process for requesting changes. That’s a big one. Sometimes the requester doesn’t communicate clearly what they’re asking for, so if it’s a DSMO change request or it just comes in as a DM, we may have to go back to the submitter and ask for further clarification. And then there’s the timing issue, the coordination between the regulatory authorities and the SDOs.

Recommendations. X12N is committed, as well as X12, is committed to working with the DSMO to gain efficiencies. We support the DSMO recommendations. We’re also developing a how-to primer, so you have a question about a standard. How do I do that? Where do I go? I have a question about how do I make a change to an implementation guide adopted under HIPAA, how to do those type of things. So it’s not a “how to get around an X12 meeting,” it’s more of a “how to do certain things.”

Found that we believe this is necessary. Do something in a pretty clear cut step one, two, three, four type of thing. We continue to streamline our process. We’ve streamlined our process to where now we can develop a TR3 within two years. That’s a great streamline to where it used to be. We continue to evaluate that process and we’ll look for further enhancements to that.

Another one of our recommendations is, there needs – and Judy, you alluded to this with your primer – there needs to be clear-cut criteria with what’s an operating rule versus what’s a standard versus what’s a technical report or an implementation guide. The industry is going to be confused with what’s an operating rule, with what goes into an implementation guide. The SDOs must control the data content and the business rules required to support the data content in the technical report/implementation guides.

Effective dates of the operating rules must coincide with effective dates of the HIPAA-mandated transactions. Now I know originally with the legislation that’s not going to occur, but going forward they need to coincide, otherwise we’re in a never-ending cycle of implementations.

The operating rule entity or entities need to – must collaborate, not need to, must collaborate with the SDOs and the data content committees. One, determination of modifications. They need to go through the whole adoption process, and we need to establish a predictable process for versioning these type of things.

Lorraine asked for some comments on some other questions in regard to operating rules. I have included those here. She also asked about increasing participation in the workgroups, specifically around providers. And we are trying to have more virtual meetings. One of the things we’re looking at is creating value statements. Value needs to be put on the type of work that we do by organizations. This is critical to the industry, but yet there’s some companies that don’t see it as value. They let somebody else do it.

The vendor community typically participates versus the end user. And then to allow participation without requiring membership. That would be it.

DR. WARREN: Okay, Lynne, you’re up.

MS. GILBERTSON: Hi, I’m Lynne Gilbertson with the National Council for Prescription Drug Programs. Next slide – this is the typical overview of NCPDP. I won’t read it, but we are an ANSI-accredited standards development organization servicing the pharmacy sector. Next slide – As in the X12 presentation, NCPDP takes it very seriously as part of our standard procedures by ANSI that any interested party can submit a request for an enhancement to a standard or a project. You can be a member, you do not need to be a member, you need to be an interested party though. You can’t just throw something over the wall and hopefully somebody else will pick it up and take it and make it stick. We need contributors to the requests.

Enhancements can be brought in via questions that are submitted to NCPDP staff, or via our task groups which are open to any interested party and communicate via conference calls, usually weekly or bi-weekly. After the request comes in, it may become what we call a DERF, just an old term we use for a Data Element Request Form. It’s just a submitted requested change. It may come in through the DSMO system as well, and eventually a DSMO change request could go into the same DERF. It’s just a request for the change. And as the steps are outlined, the submitter is notified as you move through each of those steps, so they know what’s coming and what has been processed.

The current process for these DERFs, the request forms, are – every quarter we meet face to face and discuss the requested enhancements that have come in. The submitter is either asked to be at the meeting so they can represent any questions that might come in from the participants, or a workgroup co-chair or staff will be very glad to assist in that process. The DERF may be approved or approved with changes, and then if it’s the type that would proceed to ballot, proceed in that step. A DERF may be pended because there’s more information either needed by the requester or it affects more pieces of the industry than what was thought, whatever. A DERF may also be denied with a reason given for that denial.

If the change requests proceed into the ballot, then there is not only voting and comment period opportunities that go along with every ballot. When the ballot has completed its cycle it must meet approval requirements of percentages that are in our procedures. All comments must be adjudicated and if the comments are substantive they will then recirculate the ballot. And upon approval the implementation specifications are then published. There is a couple page diagram that was also included. This is just for those who like pictures versus steps.

Some benefits of the current process – we recognize that there’s always room for improvement and we continue to review those processes with the membership to see where we can add enhancements. But the industry does understand the process or it’s pretty simple. Once the submitter says, “I need this, how do I go about getting it changed?” we can provide the initial education material of the steps and then walk them through all the processes as their request goes forward. The DSMO change request system fell into this process as well. That was nice. So that the DSMO change requests can fit into the data element request form process as well. The regulatory process fit, thank goodness, and we see that the operating rule process will fit just as well. It’s the enhancements requested to a document as far as the process is concerned.

And the one thing that’s very important about the process is that there is discussion at various steps and the industry must come to consensus on the requests that are coming forward. They can participate via task group calls, which are via conference and webinar, they can discuss things at the workgroup level, and then they also have the ballot process to put in comments as well. And even going one step further, you have the regulatory process where comments can be submitted. And we do have an established process for working with X12 as we have data element requests that might come forward from the pharmacy industry for the transactions that are used, that X12 maintains.

So the challenges we were asked to look at – and as you know I can’t stand a challenge without at least offering some kind of solutions. We need to make sure that the interim final rules that come out for the operating rules are clear, that there is a difference between the operating rules and the TR3’s, the implementation specifications. They are different, and perhaps it’s a mechanism to walk through a few examples of what would be appropriate for a change request coming forward for an operating rule document versus an implementation specification, to give the industry some real business guidance. And we’re looking forward to comments and recommendations that will come in, in that interim final rule from the industry as well.

Confusion on what’s an operating rule. As I was listening this morning I realized even amongst folks who seem to understand the process there are still questions about can an operating rule fill a gap till the next version of a standard is built, can an operating rule adjust a problem in what’s perceived to be – and all those answers are “no.” The rule is very clear in the act of what an operating rule can and can’t do. So we need to be continuing to work through the process that because the implementation specifications can be updated regulatorily faster now with the interim final rules, that those changes need to come forward to be processed in the SDO environment, not somehow the industry assumed you slide it through and put burden on the operating rules entities where it’s inappropriate.

There will be discussions that need to take place between the SDO’s and the operating rule entities. No question about that. But it is a recommendation that we do look to using the DSMO website as the portal for the industry to submit their change requests, because there has to be some due diligence that goes through those change requests to figure out what is it they’re asking for and how best would it be served.

The change requests that come forward can be – we cannot expect the industry to understand how to solve all the problems of the questions they’re asking in those change requests. We get questions in the DSMO change request system of how could I do this, or how do I solve this. And in some instances it can be a code value that’s added, so you send it to the code set committees. In some instances it’s just a question that’s being asked.

So we need the different portals for the industry to be able to submit their questions, submit their comments, but then obviously work together to get those framed up so they can be tracked and so that we know, oh, this request from the industry that for example came in the DSMO change request system, ended up showing up in a TR3, this one ended up showing up in a code set revision, this one showed up in an operating rule, and they were appropriate for that.

One of the things to bring forward is that when a new version of an implementation specification comes forward, there will probably be an operating rule update that comes forward if it’s affected. Now I have to slightly disagree with Margaret. There are times when they’re going to be very coupled. But I wonder if we will see it he future that there are some needs, for example, for an operating rule to come forward as a new version that does not affect the standard that it’s being cited for, that for some reason there is a need. So there might be something that comes “out of cycle” but I would argue that if it came through the DSMO change request system as a request for an update to version 1.2 of an operating rule, then it could follow the procedures, the DSMO review, the recommendation to NCVHS, the recommendation to HHS, and the rule-making with the public comments. So that’s for consideration.

While it’s considered, while some could consider a negative that there are multiple routes to submit requests, I do agree we need to have those multiple routes. People are comfortable with either going through their association or going through an entity that they are comfortable submitting, whether it’s the SDO, the DSMO or whatever. I don’t think we should make this single threaded, because that has its own inherent problems.

The champions need to be there. Any business case has got to have a champion before its coming forward. And if we use the established process of the checks and balances of public comments in NCVHS and then on the regulatory process, I think we’ll have the comments. Last slide.

And there was one comment at some point in the questions about is the frequency of change too slow. And I would change this question a little bit. NCPDP can publish up to four times a year. The industry may not wish to implement four times a year. But we want to keep the cycle of the updates continuing so that when the industry says “go” for the next version, the implementation specifications have everything they need up to that point, knowing that the minute we start the regulatory process the next changes are going to come in and we’re going to be moving forward anyway.

But that’s the life of the enhancements. And NCPDP is committed, we’re working with the DSMO to look at the DSMO process to see if there are some new efficiencies we can add to the process to help the industry in timeliness. That’s it. Thank you.

DR. WARREN: Thank you. John.

MR. QUINN: Thanks. Co-Chairs and Members of the NCVHS Subcommittee on Standards, my name is John Quinn. I am the Chief Technology Officer of HL7. I also hold the title of Chief Technology Officer of Accenture’s Health Provider Practice, so they’re the ones that the check actually comes from. Worth noting anyway because there’s a fair amount of Accenture activity in ONC right now as well.

On behalf of HL7 I’d like to thank you for the opportunity to share our comments on the Standards Development Process. In our case this includes both HIPAA and non-HIPAA standards, in fact largely dominant non-HIPAA at the moment, although processes for both are very similar with very small procedural difference. Now I say that with tongue in cheek because we have developed attachments twice. It’s never quite made it to prime time yet, so we have experience but I wouldn’t say we have experience with people from the field saying, “You need to change this because we haven’t had – we’ve had limited – I’ll get to that, but we’ve had limited participation in the field in what we’ve developed.

From HL7’s perspective, HIPAA specifically deal with attachments and we have a dedicated workgroup inside of HL7 that deals with nothing but attachments, and have since we started working with CMS probably around 1997, I believe. So let me help by reminding everyone that HL7’s domain is the exchange of general patient administrative and clinical information among IT systems.

Historically this has taken place largely within provider organizations where the business rules – to a certain extent operating rules – may not always be well-understood but they are at least under the responsibility of a single governance authority. Of course we have already crossed this Rubicon river of inter-organization exchange of information with the inclusion of HL7 and ONC’s meaningful use rules.

So now we are starting to deal with this issue of what do you do when the business rules and the procedures are outside of the control of just a simple customer like the CIO of a hospital. So there is – we have, I wanted to mention at this point, we have 35 countries associated with HL7, and this has been handled in a few other countries like Britain and Canada at this point. So there are some other examples; we have to work with that.

After researching, HL7 decided to improve the instructions on how to find the tools. So we reorganized HL7 certainly since ‘96 – I’m going to say about five years ago – and so just a few points of reference. One, there is a single workgroup. It reports to what we would call our domain experts section. That section meets once a week so it’s almost always available to take requests. In other words, if a request comes in through the website that says we need to change to X, Y and Z, that affects attachment.

The attachments workgroup has a schedule of meetings. It’s usually, typically every few weeks unless there’s something hot. They can call their own meeting; it’s a very limited group of people on a small mailing list. The steering division they belong to meets weekly, so any help they need in terms of proceeding with a request quickly has a maximum wait time of a week. The technical steering committee that I’m on that has to then approve those to make them formal projects also meets once a week, so usually this all happens within the course of a week, like the steering division meets on Wednesday and the following Monday the TSC meets.

Now I’m going to tell you that the flowcharts for our balloting procedures really don’t look that much different than Margaret’s. I didn’t put it on the slide; instead, I gave you pointers to it as well. Yes, when you put it in a flow chart it looks ugly and there’s no getting around the ugly looks of it. But being an ANSI-accredited SDO does not imply standardization of an SDO’s ballot process. So Margaret has hers and I have mind and Lynne has hers. We’re all ANSI-accredited.

ANSI basically says “here’s the principles that you have to work under.” Things like openness and stuff like that. And then you have to define the process and then you have to stick to the process, and if you don’t do that then yes, indeed anybody who feels wronged can, besides appealing to the HL7 board, can go to ANSI and say, “Hey, those guys aren’t doing what they said they would do.” And then I find myself in an ANSI audit. So those are things that we don’t want either.

So it’s worth noting that the standards and option process under HIPAA in general needs improvement. So we’ve come in and testified previously with X12 and NCPDP primarily because when we’ve been through two NPRM’s with attachments and we’ve had prototyping going on, beta testing going on with a number of organizations, one of them spoke this morning, Montefiore, another is Mayo. And so attachments has been informally attempted and has demonstrated a pretty strong ROI where it’s been used as well for both the participating payer as well as the provider.

I want to call out the next slide but I have to call it out of my head – so a little comment about our standards in general are developed in the context of clinical or business process models. These models at times go by names like use case description, dynamic model, and most recently behavioral models, which comes from the SOA world, the Services-Oriented Architecture world. In any case, standards provide a scope or range of supported capabilities.

So I was listening to Margaret and I was thinking like, well, so they have transactions that they really publish, and then there’s this group of things that support those transactions that you talk about. And we kind of lead with the things and then people develop transactions from that, so there’s a little bit different approach in terms of I tend to have a huge body of stuff that can go into a transaction. And HL7 tends to work off of this general concept of the domain of healthcare, as opposed to we need to support a transaction that just does attachments. So there’s the reference information model we work from tends to be very rich.

Because of that one would say that we probably waste our time in many ways by creating a lot of stuff that nobody’s going to use, or stuff that only Germany wants to use, or something like that as well, and there’s some truth to that. So by the way, at some point it would be a good idea to ask the question how are functional or semantically complete electronic acknowledgements – I want to bring up the point that it applies here as well – handled in clinical care transactions today?

And the answer is in general not. So there’s typically an interface engine sitting on the end that we’re attached to, and if the transaction makes it through the interface engine, it goes. It may make gibberish sense to the target system, and it gets dropped on the floor. Now the outcome here is a little worse.

I mean, admittedly cash flow is important, but here it might be the medication doesn’t get delivered or the diagnosis isn’t made. So the IT department typically ends up with some sort of a log that they have to have somebody constantly watching to see if a transaction bounces, so to speak. So these acknowledgements play a role here as well, and it’s important to understand even though I didn’t speak in the first half of the day here.

All ballots have 30 days prior notice and 30 days for a ballot to be completed. So those are the time frames I have to deal with. And they could be changed but given the scope of our ballots it’s pretty hard to ask somebody to turn around a ballot faster than 30 days, and it’s understandable, they might want to make sure they’re not on vacation when we publish the ballot and stuff like that, so it’s good to have notice as well.

We do balloting three times a year, so it pretty much falls into three cycles, that 30 days prep, announcement; 30 days to do it; 30 days pretty much to take care of it afterwards, and that pretty much eats up the year. And so we have three meetings a year and each one of those meetings reviews the previous ballot and gets ready for the publication of the next ballot. So that’s a pretty constant cycle. Not every work group participates in every ballot, but anybody that has anything that needs to be balloted certainly can.

Now I have one other – we made a change in the balloting process for ISO. ISO had a requirement that said a ballot had to be at least five months. Now I realize that’s probably opposite of the direction you want to go, but we accommodated it on a separate ballot platform. They have a requirement that a standard has to be translated into the local language, and so their countries want five months so that that can happen before the ballot is actually processed. I’ve not been in an ISO meeting where the people didn’t speak English probably better than me, so I sometimes wonder – some of us do – as to why that’s necessary. But it is, so we made the accommodation to do that as well.

So, again, a frame of reference. Attachments is part of the clinical document architecture and electronic document and HL7 is based on the reference information model so it falls into that side of HL7 we call version three. The good news, I guess, from the perspective of attachments, is this is the same exact area that ONC has decided to use for Transition of Care documents, as they’re now calling it.

So CCD was the first of what’s going to be eight – that’s as of today – that we’re working on. There will be more. And they all come from the rim. So it actually helps here because we’re not dealing with a one off as much as this is something that looks very, very similar to these. This is a particular templated subset of what’s in these eight Transition of Care documents in the same architecture with the same Reference Information Model.

So, just a couple of last things, and this was mentioned before as well. We deal with something called vocabularies, and the clinical vocabulary set is really large, and really complex and rules are fired off on these concepts and values that deal with things like alerts to a physician saying you might not want to prescribe that because they’re already on it or they’re on something that would have a bad effect if they’re mixed together and stuff like that.

So just as we start thinking about DSMO processes and maintenance, there’s probably going to be a strong desire to maybe in this area do some closer work with ONC, who’s got the exact same set of vocabularies to work with the Nation Library of Medicine, who’s managing this as well, especially SNOMED. I don’t particularly want to be dealing with managing a separate set of SNOMED for just the payer industry, and I can’t imagine that CMS or anybody else really wants to do that either, as we get into that.

As a policy we don’t develop our own terminologies if we can avoid it. We have what we call structural vocabulary for things like saying this is a segment, and the message header in this spot tells me that it’s a trigger event that says “admit a patient.” So that’s the level of terminologies we deal with unless we just absolutely can’t find it somewhere else, which is very rare now.

And finally, the other good piece of news here for the maintenance processes as well, and development processes, is that ONC, since they are using CDA, has been working closely with the Veterans Administration who developed a set of tools along with the NHS for being able to take the content of the Reference Information Model and put it into a template. So a set of graphable tools for being able to create the subsetted model of what is the attachment here applies as well to this group, and that’s a lot better than trying to deal with the RIM in its native form, which we call myth, okay? All right, that’s all I’ve got.

DR. WARREN: I think in a matter of timing and questions, is Gwen here? Can we have you come up and give your presentation and then we’ll take questions of all four. While Gwen’s getting ready is there any questions that we can handle that are quick for the panel?

Agenda Item: Questions by the Subcommittee

DR. SUAREZ: I have questions, but they’re not quick, though.

MR. FITZMAURICE: Quick question, probably it focuses on John, but you described HL7’s claims attachment as RIM-based, it’s object oriented, and yet this morning and earlier this afternoon, we heard that most claims transactions are EDI. You also mentioned that HL7 tries not to offend its vocabulary but uses vocabularies as they exist. How do you merge together an object-oriented CDA document with an EDI transaction? And then secondly, how do you coordinate the vocabulary so that the terms are used the same by NCPDP X12 and HL7 for claims attachments?

MR. QUINN: Okay, so the first question is relatively easy – short, and that is, the 275 has always been the concept of an X12 envelope around content, clinical content. So we handle it by objectizing it, so to speak, and putting the clinical content in the X12 envelope. So the transition route, the sending, the routing, the stuff that operating rules and implementation guides, the TR’s, normally deal with, really for the most part that you’re familiar with, sits to the envelope as to getting it to the destination. The content then, yes, you’re right, the receiver, whether it be in this case more likely a payer, the good news is there’s more and more incentive for payers to really want this because care plans having access to clinical information in general facilitates the business. So I think most payers can handle this. If hospitals can handle this I think payers can handle this. I have a hard time remembering going and talking to a payer that didn’t have a lot of really good physicians in the care plan areas, and when I spoke of these things readily started nodding their heads and understood exactly what I was talking about and saw how that would apply, so that’s where I’d leave it at this point.

DR. WARREN: Okay, Gwen, you’re on.

Agenda Item: Session 2.3: Overview of Current Maintenance and Modification Process for Operating Rules, Gwen Lohse, CAQH CORE

MS. LOHSE: So thank you for inviting us to talk about operating rules, updating and maintenance. For those of you that don’t know me, there’s a few unfamiliar faces here, I’m Deputy Director of CAQH and Managing Director of CORE. And CORE has been focused on the development of operating rules since 2005, and CAQH has been sponsoring CORE. CAQH is a sponsor and then CORE is 100 and – it’s now 35, 135 companies, mix of health plans, vendors, providers, the SDO’s that have been working on the operating rules over the last six or seven years.

Right now, we’re looking at – ACA has obviously amended HIPAA, so we’re being asked I think as an industry to think about what can we do faster and different to really bring value and cost down. And the ACA amended HIPAA under the Administrative Simplifications section, so CAQH itself has been devoted to administrative simplification and that’s one reason why we sponsored CORE.

So as I walk through my comments I’m really keeping that in mind as to what we’ve done to date and where we’re going. So there’s three themes in the detailed testimony. One is setting strategy and vision to drive the maintenance and modification. So we really need to decide where we’re going, what we’re doing and why we’re doing it, because all the technical details and the edits are very difficult to do if you don’t necessarily know why you’re doing them and what the end goal is.

And then the governance that supporting a practical maintenance and modification period across the board – and I think John brought up some excellent points with regard to, for instance, coordinating with ONC what is the governance we’re going to need to do to make this work faster, better, cheaper. I keep hearing Karen Trudel say, “faster, better, cheaper,” so it isn’t in my mind. And then tactical processes – obviously once you have the vision and the governance and the goals, what are the things that you’re going to need to do to get there. So this is just the outline we’re going to use to talk about what we’ve been doing.

Some themes before we go through what works and what could be improved within those things. The world has changed quite a lot. If you think about when HIPAA started to now, HIPAA’s been amended by Section 1104. So we have to have a new vision and it has to stay at the forefront and be nimble and business-driven, and I think John mentioned business cases a few times, trying to get adoption without the business case is tough, and aligned with the clinical efforts which CORE has spent quite a lot of time doing.

Strong governance and solid funding – all these activities that are happening take minds and people and how are we going to get that moving and funded and staffed, and get all the volunteers that are really driving the process, get them easy tools that are helpful. The tactical process, making them adaptable and capitalizing on the rapidly changing environment, so as we think about these aggressive ACA deadlines, obviously all the tactical pieces are going to have to have ballots, time periods, but we’re going to be a little bit under pressure at this point now across the board to say, “What can we do better, what can we do faster, and how can we do it faster and better and cheaper?”

And then ongoing coordination between the operating rule authors and the SDO’s – I think I want to comment here before going into what’s worked to date and what can be improved. What we’ve seen within CORE is, we’re getting greater adoption of the standards. So you’re seeing, there’s 130 million lives impacted by the CORE health plan certified entities right now. It means they’re using in and out of network variation, year-to-date deductibles, SOAP and web services, acknowledgements, which we spent this morning on. So we need to think about what is the goal that we’re getting to and what has the experience shown us. So we are getting greater adoption of the standards, return on investment and more industry coordination, which is the only way this is going to work.

So setting the strategy and the vision here – with today what’s worked, just as a reminder, CORE has been an integrated model, so there’s rule-writing but then there’s certification and testing, so for every single rule there’s a certification test script associated with the health plan, the vendor and the provider, really outlining what they need to do and then if they want to become CORE certified, they have to go and get independent testing and it’s all on line. So then the outreach and the education, just as an example, the AMA yesterday did a web session with CORE and NACHA on EFT and ERA, with all their federated staff, and we’re doing another one tomorrow. They all play in to kind of making this work and thinking about what we’re going to prioritize. Nimbleness and transparency, I think we heard a lot from Lynne and Margaret, more use of the web, making everything transparent so it’s easily accessible. And then milestones across the board to say how quickly can we get there and how are we going to get there.

Strategic dialogs and research to drive collaboration alignment, and I’m just going to show this slide for a minute. Given that NCVHS recommended that CORE try to develop a set of vetted operating rules to you by August 1st, we obviously want to build off of what exists. So one of the things I think that is working under the operating rule process right now – and this is similar to other activities on the FDO’s – is industry research. So identifying what the opportunity areas are, reviewing and evaluating business criteria prioritizing, and then focusing on the top areas. And we’re doing this through what else exists. There’s a lot out there that exists, and how do we coordinate and build and prioritize off that, and then focus on those things that we can get done.

And this requires a lot of dialog back and forth between entities. So for instance, the CORE rules did a comparison between what rules existed in Minnesota, the State of Washington, the State of Oregon, to say where are the similarities, and maybe we can drive there.

Ongoing business cases – so once you do decide where you’re going to go, figuring out the business case and really getting that documented before you do the details and the modification, and then stakeholder input. I think a lot of people have focused on making sure that not only those at the table doing the day to day work, but also then those that aren’t as involved, have a way to access. And everyone doesn’t want to be involved in every level of detail, so doing things like town hall calls – I think CCHIT has been successful with that, some other efforts we’re seeing. So how do we try to do more of that? And then results in tracking to drive the adoption.

So what are the opportunities for improvement? As we think about strategic analogies on an established cycle, administrative simplification is going to call for all of us to come together to day what do the operating rules need to focus on, and writing those strategic analyses about every two years. We’re doing that on kind of a yearly basis within CAQH CORE, and it would come across the industry every two years, and they’re going to need to address things like mandatory and voluntary rule adoption where maybe you have a base, and for those that want to go above and beyond an advance, because we’re going to need to constantly be moving forward and not moving forward in different directions but moving forward together.

And then additionally vested interest – I think across the board as we know the operating rules build on the standards, so how do we continue to recognize and promote that we’re getting more adoption for the X12 standards, for instance, working to get adoption for SOAP and web services. I think everyone, whether the core rules were integrated into HTSPE, for instance, and they put some constraints on them. So that was our vested interest, is “are we okay with that” and we were, and then in other instances maybe some people won’t be. So how do we address that if we’re going to merge all these things and move forward? And it’s going to be essential we do that. And then more extensive ROI tracking.

So for the governance, and this is a key piece, really having guiding principles that set the parameters for modification and maintenance. If you think about the EFT and the ERA, and this is the same way the eligibility, the claims status started. What can the operating rules do right at the beginning? There’s no point in working on a modification or a maintenance if it’s out of the scope. It’s a waste of everyone’s time. So the things that aren’t within the rules need to go over to the standards.

And then really laying out what they can do and what they can’t. And within CAQH CORE we’ve spent quite a lot of time thinking about what the rules can do to build off of the standards and really aligning this to make sure we’re not rewriting anything, we’re supporting what exists in the standard and what exists in the implementation guide, and targeting where the priorities are to get the adoption. And you’ll see on the bottom, for instance, acknowledgement in scope, things like that we’re saying build off of the standards and get more adoptions so the HIPAA-mandated standards can move faster, better, cheaper.

With transparency and balance we – all the CORE rules are free on the website, so anyone, whether you’re a CORE participant or you’re not a CORE participant, the rules are up there. You can download them. You also can see all the draft rules and you can see quite a lot of the research. So how do we make sure, again, for those people that aren’t at the table, that we can do things like that and that obviously requires resources. And then additionally, as we think about the decision-makers, in the CORE operating rules they’re the volunteers. It’s the people that are going to need to adopt this.

And on page 13 of the detailed testimony that we submitted, similar to what John commented on, I didn’t go through all the levels of voting but it’s a multi-tiered voting process. There are quorums required, so if a rule doesn’t get through a quorum it doesn’t make it up because we can’t get the priority and the support for it. And then there’s tracking of all the comments, which again, takes staff, and then sharing it publicly with all the participants. There’s several workgroups, and I think John made a great comment, not all the groups are going at all the same time. It really depends what did you decide to prioritize and those are the groups that are working.

And then I think there was a comment about not all the members of CORE get to vote. At the very last vote – so it’s a multi-stage voting process – it’s only the entities that have to implement. At that point anyone that doesn’t have to implement does not get a vote because they’re not going to live, breathe, and spend all their resources adopting this. And that’s what the CORE participants had decided when they laid out the voting process. You’d have these groups and then at the very end vote.

It’s only the ones that have to implement. And as we think about straw polls and the other pieces, there’s the layers of the voting, and then we do quite a lot of straw polls and try to get people’s feelings to make sure, have we made a technical error for any reason, are heading in the wrong direction? And those are quick turnarounds and they set the stage for us to be ready to have things that are solid. And those are fast, but they can be a week – we just had one, it was a survey, a two-week survey on line for both CORE and non-CORE participants. And it is fast, but these deadlines are quite fast too so we’re all going to have to work to try to meet them.

With other things, the volunteers and paid staff, we have CAQH CORE staff that supports the CORE participants. They help with getting some of the agendas together, doing the research, doing comparisons against the state efforts, helping summarizes the surveys, doing minutes, because there’s minutes required for every single call. So they’re solely there as support, that’s it. They don’t make any decisions. They don’t vote, and they are really focused on what do the participants need to make their effort work.

Opportunities for improvement – you’ll see based on our testimony from – I want to say July and then now also in December, CAQH made a commitment to transition CORE’s governance, and I think NCVHS received a letter from the CAQH Board that we’ll be doing that. And we made a public release about the members of the governance committee, and that’s in Appendix A of the detailed testimony, and you’ll see that based on that appendix – and I’ll go over the timeline – these aren’t necessarily the same people that sit on the workgroups.

Linda Fishman, who’s the Senior Vice President at American Hospital Association, is the person that was quoted in the release. Joel Perlman, who’s the Executive Vice President of Montefiore Medical Center, is on the group. The CIO from WellPoint sits on the transition committee. We do have a person here, an AMA Board member, that’s a practicing physician, is on the transition committee. And then for another example you have the General Counsel for Blue Cross Blue Shield Association. So there’s a mix of health plans, vendors, two vendors, and then providers. And the vendors represent small providers that are going to rely on their systems, and then large vendors. So making sure they have that track.

The timeline for the transition committee is here. So as we committed we began inviting the members, made sure it was multi stakeholder, started discussing the charge and the general timeline and the process and announced the committee. They’ve already met, had two calls and then they’re meeting in person. And then you’ll see they’re working on some evaluations and assumptions, and we’ve brought some experts to the table who can talk about governance, talk about funding models, and the goal is towards the next quarter to solicit feedback on the model, make adjustments, and try to transition by the end of the year.

So as we move forward transitioning is going to be important. Having skill sets that really can focus on the mandated aspects of this, and then getting more stakeholder involvement. I think we’re all committed to trying to get more people to the table and the best way to do it.

With the last part, the technical and tactical processes here, as we think about what we’re doing moving forward there’s a few things that are driving the tactical processes – the definition of the rules, the CORE process within the CORE rules, the regulations, and the strategic efforts. Public access to the rules is in the modifications, high level analyses and project plans. When we did the 5010 analysis, there was first a high level analysis about what needed to change. It was vetted and shown with the CORE participants for a number of months before the detailed modifications were made, and we put a link in your detailed website on that.

So the detailed modifications were driven by the high level work plan. That also occurred when there was an analysis on TLS versus SSL as to which one was going to be used. So again, high level analysis and then determine if you’re going to modify.

Operating rules really can come before or after the modification of a standard. You’ll see, for instance, in the 5010 analysis, everything has been removed that’s now in 5010 that was in the CORE rules. And anything that isn’t in 5010 – and again CORE Phase I and II were written in 2005 and 2006. They’re still in the rules. So some examples of things that are still in the rules – in and out of network variants, year to date deductibles, the acknowledgements. So supporting the use of the non-mandated aspects of a standard that are really needed for administrative simplification. And that, again, if you’re an entity and United just went through both 5010 and CORE Phase I, II certification, you can do the rules and you can do the standards. They need to work together. Page 16 of your detailed testimomy kind of outlines that.

So as we’re moving forward, what does not work? We have a process for doing substantive and nonsubstantive updates that works, and then dealing with mandates, we do think that you can do two- to three-year time cycles. So right now we’ve see within CORE as a voluntary effort building off of standards, following that definition, both HIPAA-adopted standards but also non-HIPAA standards like SOAP and web services, the acknowledgements, etc., you can do two- to three-year cycles. It’s tough, but it’s doable. It’s just a matter of coordinating and leveraging the investments that others have made and that you’ve made and working towards that goal.

Opportunities for improvement – speaking to the strategic vision, I think John brought up an excellent point about what’s our dialog and the layer of alignment we’re looking for. Are we looking to align on a transport, an envelope, a metadata, a payload level? And we outlined this in our testimony on page 20. So keeping that goal in mind, if it’s just payload we should focus there, if it’s transport and payload we need to focus at both of those places. And I think, again, coordination with the clinical and the admin is going to be absolutely essential because then that decides, if you’re going to try to coordinate with them you’ll probably have to focus on different layers.

Increased transparency and use of existing information – there’s a lot of good work that’s already been done and a lot of it’s accessible. Now we have to use it. It’s out there. How do we decide to adopt it in a national dialog? And having more established participant review and feedback periods. We have established dates and periods as the timelines get really aggressive and everyone has limited resources, especially those within the provider side, how do we get feedback periods that are going to allow us to meet the deadlines? We’re going to have to work together on that.

And then addressing the process for standards and modification, and the availability of public tools. I think you’re having a dialog here today about what the role of the DSMO is. You received testimony from us in December about whether or not we thought it was appropriate for operating rules to be part of the DSMO. At that time the DSMO did not think it was appropriate. And I know that’s changed, and we still think there’s some challenges to having the operating rule authors be part of the DSMO. There’s a range of standards that are non-HIPAA standards that pushed the HIPAA standards forward that aren’t part of the DSMO yet. So Oasis, WC3, the digital certificates, how do we make sure they’re starting to be involved? And also there’s an ability for the DSMO to do a lot more dialoging on the coordination. And we’re really happy to work with you and work with the SDO’s on that process.

And then continuing the evolving coordination, I think across the board we highlighted again, we want to support the adoption of the standards and also the strategic vision. So how do we use both HIPAA standards and non-HIPAA standards to get that national use? And we’re happy to work with you. We think that as you’re seeing already in the last five, six years with the CORE rules, there needs to be other standards, industry-neutral standards, for instance, that push the HIPAA standards forward, and they’ve got to be part of the process because people are adopting them already right now. And the adoption is not going to stop. The states are moving forward one way or the other, so we have a real opportunity to have a national vision if we take advantage of that opportunity. Thank you. I tried to go as fast as possible because I know we’re tight for time.

DR. WARREN: So we’ve got Mike’s second question and then I know that Walter and then —

Agenda Item: Questions by the Subcommittee

MR. FITZMAURICE: So the question gets to the payload part. How do you make sure that the payload is understood by people who receive it at a lot of difference levels? That is, the clinicians who might have to feed into the claims attachment, that claims attachment might be the whole electronic medical records. The clearinghouses and the payers might have to translate and turn it into answers to the business questions that the payers have about is this procedure really necessary, is this a correct diagnosis? So how do you coordinate across these deals?

MR. QUINN: First of all, I’d have to go back to the last definition of the attachments transaction, but I don’t think there’s an option, from the entire medical record, at the moment anyway.

MR. FITZMAURICE: I’ve heard rumors that sometimes providers send the whole, entire record to the payers. Just a rumor.

MR. QUINN: That’s a desperation moving paper, and I understand that. I’m talking something you can do from your computer system and still maintain privacy. It would e hard to actually do that.

MR. FITZMAURICE: I grant you we’re not there yet.

MR. QUINN: Okay.

MR. FITZMAURICE: But it’s how do you coordinate across X12, HL7, NCPDP, and maybe other standard and code set maintainers. To use the same code sets, to use the same numbers, doesn’t mean the same thing. Marital status, male/female, the gender, it goes on and on.

MR. QUINN: So this would be a better question to have at ONC only because they need to do that, the very same thing, or the general care of a patient which is going to occur hopefully the claim with its attachment is sent. It’s also something that’s prepared to do as their domain. So I guess this all keeps going back to, when it gets to the actual content of the payload, we’ve talked about it over the years in relatively general terms because we were only dealing with it from the point of view of adjudicating a claim as it relates to a payer at that time.

Now that we’re dealing with electronic medical records as being the expected norm, not the exception, based on ARRA – I mean, the whole purpose of this is to get the adoption of the HR systems. So then that says this intensely enables attachments to actually be doable from almost any physician’s office or any hospital. So your question really needs to be revisited because the first two rounds of going through this with CMS was under the free ARA HITECH ground rule that said everybody has, the expectation is that everybody has, every provider has an electronic health record system certified that meets meaningful use that should be able to do all these things. So the demands that it’s possible to put on them is much more realistic to what the care is that’s being given to the patient on a routine basis.

I think one of the real problems with adoption previous to ARI HITECH would have been okay, I’d love to meet the operating rules requirement that I send this as a 275 but I’m going to have to sit there and type all this information into a screen because I don’t have an electronic health records system an I’m taking it out of a paper chart.

MR. FITZMAURICE: So essentially you’re saying that it’s hard to do the coordination across the SDO’s, that it takes a data tsar, say an ONC, maybe in partnership with the CMS, to put out the requirement that then the SDO’s can —

MR. QUINN: In general. We’ve lived pretty peacefully over the years, through the HITSP process there I didn’t notice any blood on the floor. It’s a lot better than it used to be 10 or 15 years ago as where we overlap, how we try to avoid overlapping, how do we make sure that each one of the SDO’s essentially has an area where they’re really good at something.

MS. LOHSE: I just would add to what John said is, within the administrative arena trying to align with the clinical arena, within the CORE process to date, one of the things that the corporate has tried to do was prioritize administrative items that matched up what clinical was doing. And so I think if we can pick a few areas that we’re going to prioritize, it sets the map for how we do things like you’re talking about where you do have exchange between the two, but you’ve got to pick a few areas where that prioritization is agreed upon, and it drives the coordination and the alignment. And I think it’s very doable and there’s a lot of very positive work that is happening at ONC, but within the administrative arena, if we are going to align with clinical, picking the priorities. But the industry also making the commitment, it wants to drive forward and focus in those areas. We’re going to need everyone at the table to do it.

DR. WARREN: So just to remind everybody, remember that part of HIPAA was approval of code sets, so that’s where we’ve come up with SNOMED, ICD-10, CPT, RxNorm. Those were all recommendations that NCVHS made a long time ago and are now finally working their way through the system.

MR. QUINN: A long time ago I had a conversation, a long time, like four or five years ago, a conversation with a CIO of one of the Blues and I explained to him attachments. And he listened and then he said, “That’s really,” he says, “Right now I’m incented to not ask for attachments because it costs so much to get the paper and all the paper that are required to either receive the faxes or the scans or the actual papers that are sent in the mail or whatever, and to analyze them and to prove the claim.” He said, “If I had attachments…” He said right now, you know, at that time he said it was like there were only four reasons why they would ask for claims. He said, “I can think of hundreds of reasons, especially with the advent of care plans, as to how they would want to use that information to manage the patient’s adherence to care plans.”

And that’s where this really gets interesting. And I agree, but it’s – because obviously ONC has picked up that same CHI report and used it, and this is just taking us to the next step. But there’s a really strong – once we start talking about the payload of the attachment you’re really talking about a strong incentive to a line with the payers, with the providers, with ONC, with CMS, because nobody’s going to be able to figure this out if everybody does it differently.

DR. SUAREZ: Thank you. First of all I wanted to thank you for the testimony and for providing some very good recommendations on how to help clarify and improve this process. I know we all have been thrust into this by virtue of the Affordable Care Act and we all recognize certainly and have acknowledged of course the value of standards, the value of implementation specifications, the value of operating rules. And so now the question is really how to harmonize all this into a way that works best for the industry.

So my question is about the timing, and how one can help leverage the other, one meaning the operating rules can help leverage the standard. So we have today the implementation of 5010 starting January 1st. X12 is all ready working and have all ready approved basically and adopted the next standard, a few versions ahead of the current standard to be implemented starting January 1st. But it’s likely that the next version, 6020, 6010, whatever that could be, could not or would not happen in, say, four or five years. We don’t know. We haven’t even started to think about when that would be. Yet there are some things that can be, well, through the DSMO process and through the input from the industry there’s been certainly ideas on recommendations on how to improve, and that’s what new versions are for, to improve the previous version.

And so there’s been some argument about how we can begin to bring forward some of those benefits of the next version or two versions ahead of the standard that is being required to be implemented, into operating rules, and move those, and have them begin to be used early in the process so that they can be later on then adopted in the standard and sort of mainstreamed into the standard itself.

So the question is, do you see that possibility, do you see a situation where okay, we have 6020, and 6020 has all this 35 or 60 different changes and improvements to the standard, but they’re not going to happen until 2015, or who knows, 2016. Can some of those be brought into the operating rules, as part of this dialogue between standards and operating rule organizations, and saying, I mean, they’re the same people at the same time, at the end of the day. It’s the providers and the payers implementing the standards, implementing the operating rules, and realizing that the next version of the standard is going to bring all these benefits, but we need to try to bring them sooner. Can they be incorporated into some operating rules and be adopted?

MS. GILBERTSON: Now you mentioned the X12 environment, so I won’t answer for that, but on a general, “No, absolutely not, please.” If the intent is for some new rules or requirements to come forward that go into another version of the implementation specification, and the industry wants it, then we’ve got to get it adopted into regulation. Putting it in an operating rule means you’re still going to have to implement it according to that rule, and you’re going to have to put it into regulation anyway, so we’ve just chased our tail at that point.

And an operating rule is not an interim implementation specification, so those kind of rules need to be going through the process, and if it’s the industry needs it, then we’ve got to get it out there for them to use whether it’s interim regulations or however you can get around the Administrative Procedures Act to get people allowed to use it, because it’s an exception to the rule or something like that. But it needs to follow that existing process; otherwise, we’re really going to have a mess, I think, as you – how do you try to marry all these things back together at some point in the future? You’ll always be chasing your tail.

MS. WEIKER: And from an X12 perspective, I would agree with that. If there’s a change that’s needed for 5010, let’s say, bring it forward. There are procedures within X12 for errata, which we have used, there’s emergency processes so if somebody says, “Oh my heavens, this won’t work for the podiatry industry because it can’t do shoe size,” or whatever it may be, there’s a process in place. This is all going to be regulated. Operating rules become regulated just like the implementation guides and they’re going to be on a cycle just like the guides. After the first adoption then you look at every two years this group or a group to be named reviews operating rules, implementation guides, and makes a decision of whether we go forward with the next version type of thing.

So if there’s a change that’s needed, it needs to go into the appropriate place, which is either an implementation guide if it has to do with the business rules and the dated content of a standard, or it goes into the operating rule. But don’t mix and match it because all you’re going to do is confuse the industry, and operating rules by the legislation cannot change the standard or implementation specification. I think it’s pretty clear on that one. So don’t try to jerry rig or ricky doo anything into the imp guides; it’s not going to work.

MS. BARBER: This is Stacey speaking from the position of the DSMO. The DSMO feels very strongly that operating rules should not be used as stopgaps to problems with the implementation guides.

MS. LOHSE: I have another thought on this, just as a different perspective, just based on the experience today I think we know that the operating rules do not repeat or vary from the standards. That doesn’t happen because the point is to get more adoption, get the ROI moving, get people focused on where we’re trying to go. If there’s items within the tools that we all have – as an industry we have certain tools that we can use and that’s all these are.

These are tools to get us to our end goal. How are we going to use the various tools to get us to our end goal? And should it be, for instance, there’s items within the CORE operating rules that had support that didn’t make it into the updated versions of the guide, even though they were out there for a two-year period. Why that is, I think one of the reasons why we have the ACA is we just need to have a more nimble process and we need to figure out how to use the tools that we do have in the most nimble way to get us to the goals that we have. So I would ask that we think about your question maybe after this, and we can get back to you with some thoughts on it.

DR. SUAREZ: And if I may, I’m going to turn around the question – and this will be also to think about with the feedback here and after we adjourn. So what about the reverse? What about elements on this operating rules that have been now implemented and are being used? Can they be moved into a standard?

MS. LOHSE: I would hope they do. As an example within the CORE rules, we struck out everything from, you know, again, 2006 that made it in, or 2007, and really tried to share and say, you could require this in the guide, there’s support for it, let’s try to go there.

So absolutely, I also think we need to be careful that each SDO has its – and I think John made a great point here – each SDO has its own area, so how do we make sure for the operating rules that relate to an SDO, drive them into that area, increase the adoption of the standard, take them out of the rules, but make sure it ends up within the right SDO. And that’s one of the challenges because things like SOAP and web services or response time, and you can’t – with acknowledgements need to be paired with a response time because if you don’t have a real time response, in 20 seconds or less you have a different view o acknowledgements, whether they’re required or not. So I think there can be absolutely especially the data content to go right into the standards.

MS. WEIKER: Well, and Walter, to the point Gwen made in regard to the rules and bringing things into 5010 and the fact they didn’t make it – the industry never brought those to X12 to have them added to the standard. Nobody brought to X12 to make accumulated deductibles a mandatory data element. It’s a situational data element in the guide now with a situational rule. Now what X12 did was, we took the CORE Phase I and Phase II rules and put them into our changed management group. X12 did that, not the industry, not CORE, X12. And we put them into the process so they would be reviewed through the 6020, go through our consensus building and that type of thing. So those type of things, they have to be brought forward to the industry. The SDOs are driven by business requirements that the industry brings forward to them. So shame on everyone if it’s such a great thing, for not putting it into the guide.

DR. SUAREZ: Thank you for bringing that up because my last question is about exactly that. So we have a very open process. I’ve been in all the groups, and I see the openness. I am actually humbled by the amount of time that volunteers put into these processes. But we still have the issues of not being able to bring it up.

So one other point – and I think that’s what’s brought in by my colleague, Jim Whicker. So we have here this announcement about provide us input on what changes need to be done on 5010 to go into 6020 and 6010, the next version. So how can we – in reality – be able to provide feedback on a transaction that hasn’t yet been implemented, so that we can incorporate those changes into the next version of the transaction? I totally understand the process and the urgency to receive that feedback on the X12 side, but if the timing is so early to a point that nobody has used 5010, it’s not even legal except for a few months after January of this year to begin to implement both 5010 and 4010 for transition purposes. So it’s only two and a half months maybe, because I think it was February 15, the deadline, or whatever day it was.

So it’s been a very limited experience with the version that’s going to be implemented to be even able to provide input on the next version, so how do you see that being able to be accommodated in a more timely fashion that allows for experiential feedback to be provided so that changes can be effected into the next version?

MS. GILBERTSON: This is from the NCPDP perspective only – sorry. Remove the regulatory process. I hate to say that, but if industry wants a change and it’s in – let’s see, we’re using the X12 vernacular, so it’s in 6020, and it’s important to my business, and I’ve got trading partners that would like to do it, we’d like to move forward. But we can’t because we’re regulated, and if we use a named transaction in a non-named version, we could be subject to compliance issues.

So to some extent, everybody is waiting to be regulated to do something. As I was listening this morning I wondered if the acknowledgements are good business practice why do they have to be regulated. But we seem to have a chicken in the egg there with that’s the only way you’re going to get them adopted is if whatever. And I realize that removing the regulation is not an appropriate answer, but it has stifled that business process moving forward.

We have task groups that meet to solve industry problems that say, “You know what? We solved this in Telecom Version 10.6” “Too bad you can’t use it. So let’s see if we can figure out a way for you to do it in D.0 and still be in compliance.” That’s a ridiculous waste of time, if the industry participants were ready to move to D.6.

DR. SUAREZ: But the rules are able to be moved quickly if the standard is consistent.

MS. GILBERTSON: More quickly now, right. And we appreciate the IFR, yes.

DR. SUAREZ: And the reality – not to continue to aggravate, but the reality is we have done this need for regulations even before HIPAA existed, really, I mean, for everything that we do. But HIPAA, we were all thinking that the standards that are out there, X12 and others, in version 3050, I remember back in the early nineties, that was where it was going to save us all money so why can’t the industry adopt voluntarily. And then the industry came back to the regulators saying we need regulations adopted. And look at what’s happening with meaningful use.

You need some sort of a care to get people to begin using it and then realize that that was what they wanted. Margaret, I don’t know if you have any comments about that point of the timing, and is there any way to get some more feedback into the future?

DR. WARREN: Timing, not politics or regs, timing.

MS. WEIKER: Well it kind of goes back to, it is kind of a circular chicken and egg type of thing. There has to be a point in time where you say I can’t do any more change requests, let’s have a cut-off, get all your changes in, we’ve got to move forward. Now when you look at the X12 timeline for the 6020, you can say, “Hmm, well people should be testing, they should be tested now, external testing with trading partners.” If there’s a fix that’s needed, again, there’s a process errata emergency. Plus, there’s also a public comment period for that 6020 guide that will be coming out that says, “Oh, wait a minute.

This data element is still situational and the situation is unimplementable for some reason. Nobody noticed it till they went to implement and they didn’t notice it till they started testing with external trading partners and they just got around to that in December.”

So there’s still a public comment period that is still allowable, but you’ve got to keep moving forward, and if you wait how long do you wait? People start doing 5010 come next year. How long do you wait? Do you wait six months, a year to say, “Oh, it’s baked. It’s been in production for a year. Now let’s go ahead with the next?” Well now you’ve lost a whole year and hundreds of change requests. But there is public comment period that can be included to include those type of things, the gotchas at the last minute.

DR. WARREN: So just to wrap up, I think the real issue is how do you get meaningful public comment when people have no experience with what they’re commenting on? And that’s the nature of a voluntary organization.

What I would like to do, because we are running five minutes over now, the question still on the table – it’s become even more obvious after this session – that there needs to be some forum for the operating rules, the SDOs to get together, and then John’s thrown in terminology on top of that. So think about some structures that might help us get people to collaborate.

MR. QUINN: Let me just add – the question – you know, we’ve kind of talked about payload and attachments for claims. Attachments for authorizations where clinical efficacy is a pretty dynamic thing, so this week we see the medical community agrees that because of this test this procedure is now recommended, can’t wait 10 years for the next version of XX10 to come out.

DR. WARREN: Right, I think that’s the issue. So anybody that wants to talk to Walter and I at break, please feel free. You will anyway. Let’s come back. Well, I know this group. We need to come back at 3:15.

(Break)

Agenda Item: Session 2.4: Panel on process improvement – Proposals and recommendations pertaining to standards and operating rules. Laurie Darst, MN AUC, Pete Cutler, Washington State, Greg Fisher, IHC, Tammy Banks, AMA, Jean Marcisi, ADA, Don Bechtel, WEDI, Randy Miller, NMEH (written), Richard Donoghue, NYUMC/Linxus, John Kelly, NaviNet, Stacey Barber, DSMO

DR. WARREN: We’re going to be coming back together and our next panel is going to look at process improvement, so proposals and recommendations pertaining to standards and operating rules. Due to an accommodation for John Kelly and his airplane reservations, we’re going to let John go first, so he can make his flight. John?

MR. KELLY: Thanks. Well it’s the end of the day, there’s probably not a lot of additional wisdom that I’m going to lend to these proceedings after eight hours of testimony from my esteemed colleagues. I’ll therefore keep my comments brief, while hopefully adding some kernel of perspective and if I’m lucky, a little controversy.

Operating rules are about leveraging a standard to achieve maximum business value. The more standardized the standard, the greater the opportunity for creating business value by generating consensus of use and broad-based adoption. Every suit needs a little bit of tailoring, every new baseball glove needs to be broken in, and likewise, all standards are a little rough around the margin, and I’m not saying that the standards are not well-developed, I’m saying that wherever the SDO draws their boundary, then that standard still has to be incorporated into a business context and a business process.

There are a couple of things about standards that are inevitable and ironic. First is that by the time we’re done agreeing on the standard, it’s generally out of date. If we invented the internet today, TCP/IP probably wouldn’t look at all like TCP/IP. If English wasn’t already ubiquitous, the language of business would probably be Chinese and Spanish, and if CPU power and memory were always as cheap as they are now, HIPPA transactions would certainly be XML.

The good news is that the second inevitable and ironic thing about standards is that out of date or not, as long as we agree to embrace them, the world is a better place. In this case, something is always better than nothing, even if something could be better, and the tricky part about that is the word embrace. And I think where this committee steps in is essentially at the end of the day to tell everybody apologize, shake hands, go outside and play nice.

To pick up where I left off, if we really hope to achieve dependable automation in health care, it’s critical that we have formalized infrastructure to achieve consensus through governance. We need standards bodies who are single-mindedly focused on managing the barter components for e-business, while in parallel, operating those entities, driving business utility. As someone who’s spent the past decade deriving business utility from enabling e-commerce through standards, I’m a little too steeped in my own experience to understand how confusing it can sometimes be to see the difference between the standards and the rules.

I have, however, observed a clear example of how standards promoted aggressively by a single operating rules entity have been a resounding business success. One of the products in the NaviNet portfolio is an e-prescribing application available via handheld device and portal, and as an e-prescribing vendor, I need to be certified by Surescripts. Now technically, there was no, in the past, operating rules body for NCPDP, but unless I currently demonstrate that I can conform to the 539 pages of certification guidelines published and enforced by Surescripts, I’m not an e-prescribing vendor. And the fact that one company filled the vacuum of opportunity created by the NCPDP standard is surely a shining example of real success in dependably automating a health care process.

All they really had to do was achieve a national consensus around their operating rules. And on their own, Surescripts took the best part of a decade to accomplish this feat.

This committee, though, has the authority to at least influence, if not ensure, that the opportunity vacuum made possible by the ever-increasing number of health care transaction standards will be filled much more quickly than heretofore observed. Again, I want to than the committee for the opportunity to testify today, and welcome any questions.

DR. WARREN: As usual, comments are brief, John – we’ll try to end the day and go out and play nicely with each other, thank you.

MR. FISHER: I can go without slides.

DR. WARREN: That would be really helpful.

MR. FISHER: I’m Greg Fisher, Director of Standards at United Healthcare, on behalf of whom I present these comments. Thanks again to the committee and co-chairs and members, for the opportunity to make comments on the maintenance process and a version process.

My previous, or my testimony, has been sent in electronically. What I’d like to do is just cover some of the high points. Some of these things have been mentioned already before; they don’t need to be mentioned again.

One of the things we are certainly aware of is this long-term time between versions makes it very difficult to implement, so one of the things we need to do is figure out how to make this go faster.

But before we talk about how to make things go faster or suggestions of how it could be faster, I want to talk about some of the peripheral transactions, such as the non-HIPPA transactions. If we’re talking specifically about the non-HIPPA things like the 278 notification or the 278 inquiry, which is an authorization inquiry, on a request for additional information, the 277, and the 275 attachments transaction and the authorization 278, coupled with a 275 attachments transaction; all these things are beneficial to the industry; they all could be adopted but we need to have clear rules as to what we’re allowed to adopt and what we’re not allowed to adopt. As I mentioned before, some of the future transactions – future versions of current transactions, we are not legally allowed to adopt, so we just need to make sure that our non-HIPPA transactions are the ones that haven’t been adopted yet – get some clear rules around them.

We realize that there are regulatory constraints and administrative hurdles to overcome, but we want to outline several proposals that make the ultimate transition to new versions simpler and more cost-effective.

The following proposals and ideas are not all compatible with each other, and do not represent a single overarching view. Many of the suggestions can be combined, and some are actually conflicting. We just want to make sure we can outline a number of areas for thought and consideration without limiting the ideas to a single approach.

Obviously, the first thing we’re talking about is too long between versions – the long time between versions really means it’s more analysis and testing and more content change than if we did this more quickly. If the content changes less, the impact is less. But it also has another benefit – if the industry participants are expecting to adopt new versions or updates every two years or every three years, they may participate more often in the actual development of the standards and rules.

Along the same lines, currently we have inconsistent participation early in the process because folks are thinking it’s going to be ten years before the standard gets done, so why participate early in the process – come in at the end with your needs. This makes things more complicated in the comment process, it makes it more complicated for the standards organizations to do their job.

We think, in the DISMO process, we want a wide participation in setting priorities. Not every proposed change is a priority, and not even proposed change may be a cost-benefit to the whole industry. So we need to have some sort of business impact as part of the priority-setting process, but there are some current practices that allow that – it needs to be more standardized.

The two-year process may actually allow the business priorities to be reviewed in order – maybe the first year between versions as the high-priority items get added to a standard, and maybe the second year, the lower priority. In some way, you can look at the process and say this is a predictable order of process and we need to look at the proposed change in terms of business priority.

Cost benefit we talked a little bit about. We recommend some oversight of the process to interject priority decisions; whether it’s a third party or changes in the rules or the process is immaterial – we don’t want additional bureaucracy levels that slow down the process, but we just want to make sure that the priority changes get made quickly.

Possibly a comment period on priorities and requirements before the changes are implemented, or before changes actually get to the implementation in the committee phase would be good, and again, cost benefit analysis at many times during the process is a good thing.

Lack of clarity between operating rules and data standards – we talked a little bit about that. I think United Health Group has their feet firmly on both sides of the law here – on one perspective we would like it to be a transaction standard guided by a then usage guide of TR3 and then we follow that with operating rules. Each level would constrain the previous level without violating the rules of that level, that’s great, that would work in a perfect world.

In an imperfect world, there maybe needs to have those other items – if the guide can’t be changed, change the operating rules or create code sets or do things that make the business work. If you have critical items and you can’t get things done in the long term, then try a short term solution.

Rules and standards; We would like to see the standards developed every two years, unless there’s a three-year cycle, and then we’d ask that the standards bodies go to a three-year development cycle, like X12N, for instance. If you have a two-year cycle of X12 publications, that would allow HHS to choose either two- or four-year cycles of a version change, for instance.

The operating rules should be developed in concert with the standards and the guides, based on the delineation we talked about earlier. Again, the rules should not overlap or supersede the standard or guides unless there’s a real clear agreement in the short-term and temporary operating rules are needed until a standard can be adopted. This would be if all other things fail or if it really is expected that a version will not go in place for several years, maybe the operating rules can be used as failsafe – shouldn’t be, but can be.

Following publication of a standard and the TR3, the rules should be adapted to meet requirements that the standard does not address. Operating rules should apply to a particular version of the transaction, and not be independent of the version; in other words, you have a set of rules for 5010, and another set of rules for 6020.

Operating rules and standards should be allowed to be modified after the initial adoption if business requirements change – I think Margaret talked a little bit about X12 can change, and that the operating rules have to be the same; if you need to change the existing rules on a regular basis, allow that to happen.

We also talked about how long you have a particular version in place. We believe you should allow a longer dual usage period for a version equivalent to a level 2 compliance period. For instance, this year we have both 5010 and 4010 versions in the production environment, being used by all parties in the industry. If you allow a longer period for two additional years, that would be a total of 3 years where you could have 5010 and potentially the next version, 6020, in place, so it doesn’t involve additional systems capacity or development. We are all ready having to have two at a time anyway.

The benefit of that – it provides a backup plan in the event that the new transaction doesn’t quite perform a particular function as well as the previous one. You always have a fallback in emergencies. You have a longer ramp-up time for providers and vendors who lag behind; either who want to or who need to for their business reasons. It also requires all payers to maintain two versions at all times, so potentially an idea is just a longer ramp-up period.

Compress the timetable for implementation – allow operating rules to be created for new versions immediately upon publication of the guide. For instance, the schedule could be first milestone is the guide is published, draft operating rules at the same time, second milestone a few months later, do operating rules – third milestone, assess the impact, make your system changes and the fourth milestone, do trading partner testing and implementation and put it in place.

One of the things, also, you could allow would be to have old transactions – or transactions stay in old versions while others move at faster paces. For instance, if the 820 premium payment transaction has virtually no new functionality and does not violate a standard as is, then leave the transaction in version 10 when the others move to 6020 or 6040.

Allow willing trading partners to adopt the next planned version by agreement. Obviously, this needs a regulatory change, but the rationale is, the use of a new transaction has always historically turned up valuable information that can be captured in rules and also changes to the current guides.

Early adopters can help identify situations that may require errata to be published or changes to be made in the version. Again, flexible version schedules would require payers to support multiple versions. This is one of the caveats if you’re going to go to a flexible schedule; the payers have to be the first in the door to get the transactions in place.

Payers and clearing houses and vendors already have to support two versions in production during the transition year, like 2011, for our current 5010 version, so creation and continuation of that environment is feasible. If a player or a clearing house wanted to adopt a new version ahead of schedule, there could actually be three versions running for that pair of willing trading partners.

The transition period beginning and end dates should be established well in advance. If you expect to do a new version every two years and you publish that intention, folks will pay attention and work on that and expect to have that new version in every two years. It could be three years, four years, any number of years, but if you establish the transition period first, it makes it easier for the process to occur of analysis and implementation.

We have some concerns. There are no limitations in the existing regulations that make some of these suggestions difficult or impossible at the present time. Also the payer segment of the industry would have to support a multiple-version scenario or there would be no options for vendors or providers to exchange the multiple versions of transactions.

Shorter cycles will encourage more participation in the process to drive the standards and rules. It will help the industry to focus on cost-effective solutions and provide stability to the implementation process.
We need better initial industry oversight of proposed changes to ensure true priority items are addressed, and a more rigorous focus on cost benefit changes up front. We need to investigate new ways, both regulatory and procedural, to reduce the cycle time it takes to implement changes to support new health care products and processes.

Our United Health Group is willing to participate in the process to address faster adoption of changes. We believe that nimble reaction to the regulatory and business changes and environment is imperative to allow the industry to respond to new challenges more quickly.

Thanks for the opportunity to present our response, and I welcome any questions.

DR. WARREN: Lauren?

MS. DARST: I’d like to thank the co-chairs and staff of the sub-committee for the opportunity to present today. I’m Laurie Darst, I’m Revenue Cycle Regulatory advisor at Mayo Clinic. I’m also one of the co-chairs of the Minnesota Administrative Uniformity Committee, and I’ll be presenting today on behalf of the Minnesota Administrative Uniformity Committee, which I’ll refer to as Minnesota AUC.

You have received a brief written testimony, sent on behalf of the Minnesota AUC, which will supplement our oral testimony. Our testimony reiterates several of the concerns and recommendations that we have made to CMS in letters dated February 2010 and again more recently in March of 2011. You heard about the makeup of the Minnesota AUC today in previous testimony, but I want to reiterate today a couple of important points that we feel contribute to our success in Minnesota.

We feel that some of these attributes might be valuable to consider replicating at a national level, as they promote participation, adoption and balance.

First we have an equal representation balance of payers and providers. Voting is done requiring a quorum of payers and providers, guaranteeing a balanced vote.

Second, our meetings are open to the public and meeting information and documents, including our companion guides, are available free of charge to anyone on the AUC website.

And then third, administrative support is funded by appropriations, thereby making participation free for anyone who wants to participate.

We’d like to now turn our focus to the current state of the maintenance and modification update process. Our comments are intended to address the medical transactions, not the pharmacy nor the dental, although I’ve going to briefly mention them on one slide.

With the Minnesota AUC, we’d like to go over our three points. The current process is not as efficient as it should be. I’d like to present an alternative approach, and then also talk briefly about the benefits of change.

Let’s start by looking at the current process. Based on ever-changing billing requirements and new emerging payment models, the industry may need to request new administrative data for billing purposes. This may be in the form of actual data or maybe a new billing indicator.

To best illustrate this process, we’d like to use a hypothetical example. In our example here, let’s say we need to be able to bill for package billing or bundled services for both chronic and acute conditions. Other examples of new types of administrative data might include billing data for medical homes or maybe information to support the implementation of health plan ID.

We first go to X12 to get an indicator in the multiple different transactions. We might first seek a data field in the eligibility transaction that was specified what kind of package billing coverage that a patient has coverage for? So for example, a chronic condition might be a diabetic patient who has specific services are covered for a year’s duration, or it could be a shorter term, maybe for a knee replacement package.

An indicator would also likely be needed in a professional and institutional claim, which would alert the payer that the services should be bundled into a package when payment is made. This same type of indicator would likely be needed in remit potentially other transactions.

Our next step might go to the remit code committees, to request a number of claim adjustment reason codes, and remittance advice from our codes. Although this meeting is held at the same as the X12 meeting, these are separate committees on different timelines. We should also take into consideration the paper billing process, and some of the small providers will continue to bill via paper. If an indicator or field is needed at the professional or institutional claim, we would need to address this with the National Uniform Claims Committee and the National Uniform Billing Committee.

If a taxonomy code is needed, we would need to seek this from the National Uniform Claim Committee. Value codes, condition codes, occurrence codes, if those are part of our solution, would be requested from the National Uniform Billing Committee.

Perhaps our solution might need to have new procedure codes from the AMA, the ADA or ICD10 codes from CMS. We recognize these are medical code requests, and outside of the scope of the DISMO process, but yet another potential request, the industry would pursue nonetheless.

If the package billing requires an attachment, we might need to seek a specific attachment data field with health level seven. We’ve included the dental data content committee and NDPDP on this example only because there may be an occasion where we would need to consult them, maybe an oral surgery package or maybe a children with asthma package.

Finally, we now have new operating rules added to the process, and need to consult with the entity or entities who will be overseeing the operating rule process for each of these transactions.

The Minnesota AUC feels the time and energy that stakeholders need to invest to get everything done is costly and time-consuming. It also assumes that each one of these separate entities would agree to the same solution and make efforts to provide a coordinated response, a coordinated timely response. If entities don’t move forward in unison, or an entity or two don’t agree with the request, this causes solutions to be out of sync or can even derail the overall request.

Now we recognize there is currently a DISMO process in place which includes six of the organizations highlighted in yellow, but the Minnesota AUC feels there is significant opportunity to facilitate better solution coordination between entities. Our intent is not to criticize any of these individual organizations. They all do a good job independently. It is the overall need for coordination we feel needs to be addressed. Now, with the addition of mandated operating rules, this is another cog, or spoke, in the wheel.

So speaking of wheels, we feel the wheel needs to be fixed. We can view this analogy another way. As a vehicle going to a destination with each organization representing a different-sized wheel on the vehicle, each moving at its own speed, arriving at the destination at different times, some may even have a breakdown along the way. The Minnesota AUC feels it is time for an upgrade for a new vehicle.

This slide reflects stakeholder time commitment and cost. In order for stakeholders to have a voice in the administrative simplification process, or addressing challenges and new requirements, it requires time and money. This timeline provides a glimpse of some of the media schedules and time required to participate. There are costs associated to travel, meeting fees, membership dues, document fees, for most of these organizations.

The ability to vote on particular issues varies by organization. Some are open voting based on dues paid; others only allow designated members to vote. It is difficult for industry stakeholders to stay abreast of all the different activities with the different organizations, all with different timelines.

Another concern expressed by the Minnesota AUC is with the timing in which each of the organizations releases updates. The most stringent timelines are those named in legislation, which takes additional legislation to adopt a new version. There is too much time lapse between upgrades for these organizations, due to this requirement, although we recognize the IFR process will make this better.

Other entities have their own schedules. We feel that this disjointed update schedule may stand in the way of moving forward with administrative simplification and new concepts. In our packaged billing example, we may not even be able to implement our billing solution if entities cannot make the necessary changes along with their counterparts.

So what we need is a new approach, one that promotes coordination and timeliness across all organizations, communication, balanced representation and affordable cost.

So we come to the Minnesota AUC recommendation, an umbrella organization to manage the process. This concept would facilitate the coordination process, reduce the time spent by industry requesters, and potentially reduce overall cost. This entity could be both the coordinator of changes and the communicator to the industry.

Looking at the left side of the umbrella is the business needs. We envision this umbrella organization would receive the new business requests and provide a collaboration point between the standard organizations, the nonmedical code set committees and the operating real entities. The Minnesota AUC feels it’s important that the umbrella organization oversight committee would include a balanced stakeholder representation to ensure all points of view are taken into account when forwarding the requests to the different entities.

The umbrella organization should be tasked to establish clear expectations and timelines for the different organizations under the umbrella. They would also be tasked to providing timely responses back to the requester on the status of the request. This is illustrated by the two-way directional arrow below the umbrella.

Innovations. When you look to the right side of the umbrella, the umbrella organization would also facilitate new innovations and new billing needs, such as future payment models, including pay-for-performance, ACOs, medical home and outcome-based payment models. These new innovations need to be coordinated between the organizations to move forward efficiently and effectively.

This next slide just summarizes some of the characteristics of the umbrella that we discussed on the previous slide. We need a single one-stop shop to go to for all administrative simplification updates. This umbrella entity needs to include a feedback loop on responses and updates, it also would allow for comment prioritization -– coordinated solution. The Minnesota AUC feels that it’s essential to have balanced representation and voting on this type of umbrella committee, and this would also provide a more nimble process for innovation and facilitate meeting future opportunities and challenges.

This slide illustrates the benefits of coordinated and balanced process. We feel that the umbrella organization model would streamline the process for the industry, thereby making it a less costly process. There would be greater transparency and accountability, so the industry representatives would be aware of the status of their request and plan accordingly.

Finally, we feel that this concept provides the tools to achieve the levels of administrative simplification the industry really desires. In summary, the Minnesota AUC feels now is the time to implement changes to the process. We need this change to meet the current and future challenges and opportunities. We recognize there are considerable details that need to be worked out with this concept, but change is possible, manageable and

desirable.

Administrative simplification is the ultimate goal, not only with implementing administrative billing changes, but we also feel the need to change the update process itself. The Minnesota AUC feels the update process itself needs that administrative simplification review.

I would like to thank the committee for the opportunity to testify on behalf of the Minnesota AUC.

DR. WARREN: Thank you, especially for the visual of the umbrella.

Our next testifier is Pete Butler. Are you on the phone, Pete?

MR. CUTLER: Thank you. Sub-committee co-chairs Warren and Suarez, and sub-committee members. For the record, my name is Pete Cutler and I’m testifying today on behalf of Washington State Insurance Commissioner Mike Kreidler.

The Commissioner has asked me to express his appreciation for this opportunity to share some thoughts regarding the processes used for developing standards and operating rules for health care and administrative transactions. He has asked me to touch on four main points in today’s testimony, and we’ll also be submitting comments in writing. So just to get going –

First, the new operating rules to be adopted by HHS – it should be very clear that they establish a ceiling for standardizing health care administrative transactions. Hopefully they will be clear that they do not preclude payers and providers from collaborating on additional opportunities to improve processes and reduce costs.

States and private sector entities should continue to be able to develop as we are now, and adopt additional requirements that build upon, and are consistent with, the national standards and operating rules.

By way of example, the Commissioner’s November letter to the sub-committee chairs provided some specific examples of provisions in our state –- practice recommendations, that add additional requirements that do not conflict with the requirements of the proposed operating rules for eligibility transactions.

Second, we believe there are significant advantages to be gained by continuing to have a framework that allows for state, regional and private sector simplification initiatives. Supplemental requirements developed through industry collaboration not only add value, they can also aid in the evolution of the Federal operating rules over time.

Ideally, there should be some way for state and regional experiences and experimentation to be fed into the overall process for developing and updating national operating rules.

Our experience in this state is that it has been easier to obtain provider and public agency engagement in these administrative simplification efforts that occur at the state level rather than the national processes. The time commitment and expense of an engagement is much lower and the value and relevance of globally oriented discussions with important business partners is more evident to the parties involved.

Third, there’s a need to remove obstacles that currently discourage engagement; specifically provider and state agency engagement, in the national standards and operating rules development processes that touched on just previously, what I refer to as a pay to participate requirement and pose a significant financial barrier for many providers and state agencies. The cost of obtaining standards documents and implementation guides for those that don’t otherwise have a business need, the cost of organizational membership fees required for participation, the cost of meeting fees in travel, plus the travel time itself required for national in-person meetings, all of these really contribute, or become a significant financial barrier, and in our state, specifically, we have prohibition of virtually all out-of-state travel by state employees, which would make it impossible, for example, for our Medicaid agency staff to participate.

Another obstacle to engagement includes just the complexity and lack of clarity of the current framework for developing standards and operating roles and the duplication and overlap of roles – something along the lines that Lori proposed or Minnesota AUC has proposed would really help in terms of reducing that kind of obstacle.

So in addition, some things that could be done to address these obstacles: reducing the pay to participate expense barrier as much as possible would be helpful. Facilitating input through state and regional groups where they are operating would be helpful. Overall having the processes be as efficient, as transparent and as fair as possible, such as by having clear and well-coordinated steps and timelines for developing and updating the standards and operating roles by using technology to facilitate discussions and decision-making, by having full-time staff who support the decision-making processes, communications, by making available at little or no cost information needed to participate in the processes and by having a governing structure for the work that reflects an equal balance and is focused on the health care payer and provider perspectives while also including appropriate participation opportunities for vendors and other stakeholders.

Finally, the Commissioner appreciates the progress that has been made in the past year, and believes it deserves some recognition, and is hopeful regarding the opportunities for future progress in the future. Commissioner Kreidler and the health care payers and providers on his executive oversight group, in particular, appreciate all that your committee, your sub-committee and your staff have done to facilitate state-level engagement the operating rules of development effort. There was some skepticism a year ago that there would be that kind of openness, and we very much appreciate it.

In Washington state, several provider organizations and payers are now participating on the CAQH Core work groups for the EFT and ERA operating rules. These organizations had been hesitant to commit those staff prior to the issuing of the letter by the National Committee that identified CAQH Core as the lead initial organization for preparing those roles, as prior to that letter there was significant uncertainty about which organization would be leading the work and where it would be a good investment of staff time to participate. Resolving that confusion was very helpful.

And finally, I do want to note at the same time that I had the opportunity to participate in the X12 national meeting in Seattle in January and was also very appreciative and impressed by their efforts they went through to support my orientation to their committees, work groups and processes and -– of that desire to increase the openness to participation by entities such as our own that have not historically been involved in the past.

Now last, we would like to stress that we do; the Commissioner believes that the CAQH transition committee effort related to Core is a very important initiative and acknowledged what several speakers have indicated, that you had a major change in the health care administrative environment in terms of now with the mandatory national operating rules, and I think also what those reflect, which is an increased sense of urgency for the need to reduce administrative costs and burdens, to do it in a more timely manner, more nimble manner and to create a more efficient framework and a more representative framework for those administrative simplification efforts.

So in conclusion, on behalf of Commissioner Kreidler, I appreciate this opportunity to offer these comments; hopefully they’ve been just a little helpful. We look forward to the issuance of the regulations establishing the operating rules for eligibility and for claims attachments, and we appreciate the sub-committee’s leadership on these new national administrative simplification initiatives.

Thank you very much.

DR. WARREN: Thank you, Peter. Tammy, are you ready?

MS. BANKS: The AMA would like to thank the co-chairs and the staff of NCVHS, for inviting our input on the change request process for standards and operating rules. The AMA strongly supports the provisions in the Affordable Care Act, which are designed to fix the problems associated with the passing of information through the Electronic Health Care transactions.

The AMA has committed to working with key stakeholders to achieve positive results for physicians and their patients. We believe that the ACA’s administrative simplification provisions, including the shortening of the updated standards adoption time frame, addition of operating rules and other key initiatives that are expected to transform our nation’s health care delivery system, present tremendous opportunities as well as challenges.

With the expedited standard adoption process, we finally have the opportunity to be responsive to evolving business needs. The substitution of standard operating rules for a multiplicity of companion guides could bring about tremensdous savings. Indeed, the achievement of a fully automated claims revenue cycle would save tens, if not hundreds of billions of dollars a year. However, in order to take advantage of these opportunities, there is significant challenge that must be addressed up front.

This very simplified timeline graphically demonstrates the coordination challenges that we must overcome to ensure that the standards and operating rules are both consistent with each other and fully meet the developing business needs of a health care delivery system in the throes of massive transformation. You’ve heard of ICD 10 and 5010. In the top bar you will note that between January 2012 and December 2018, X12 will have published four versions of its standards.

Also during that same time period, there will be three public hearings, shown by the small dark stars, if you can see them, on the second row, and the red thermometers on the third row, each of which will be looking at the most recent version of the standard and operating rules for consideration. If this time line is faithfully followed, we will have implemented the 5010 version of the HIPPA standard to subsequent versions, and would have selected the third new version, all in about half the time the 4010 version of the standard will have been in place.

The third row shows the possible start of the operating rule development, if begun on the date of a published version of the X12 standard. You will note, if this is the timeline adopted by the selecting operating rule entity, there could be multiple operating rule versions being developed simultaneously.

The red and blue arrows between the X12 standard in the first row and the operating rules and the development in the third row demonstrates the critical need for lessons learned by X12 to be shared the operating rule entity and lessons learned by the operating rule entity to be shared with X12, but realize, for simplicity, only X12 and the operating rule entity are displayed on this chart when in reality, there are several additional organizations that need to be engaged in this continuous dialogue.

As this timeline shows, a change of this magnitude will require significant refinement of the existing standard and operating rule development processes. When we look at the human talent and toll required to be responsive to these daunting challenges and to successfully deliver meaningful updated standards and operating rules, we must recognize that the list of these individuals who have the expertise is relatively short. The significant demand on these volunteers who dedicate their time and resources to developing solutions will require us to revisit the existing workflow to determine how we can optimize this process and examine what additional resources will be necessary to achieve our goals.

Let us not forget – we are talking about one-seventh of the US economy being impacted by standards and operating rules. We must develop a shared vision, have support systems to translate that vision into meaningful objectives for volunteers and provide them with professional support personnel, so this group of uniquely talented individual can step up to this expedited and complex process to deliver the quality products the industry envisions and requires.

The attached timeline is as important for what it does not include as for what it has included, with respect to the activity necessary to ensure that the health care industry is able to meet the aggressive deadlines specified in the ACA. All of the following issues need to be included and operationalized in this timeline in order for the process to really work. We must consider where these essential activities fit in within this timeline of necessary actions for meeting administrative simplification goals.

Where are the optimal places for input from the DSMOs, WEDI State administrative simplification coalitions and other similar administrative simplification organizations? How do we make sure the issues of the highest priority to the industry as a whole are addressed as expeditiously as possible, considering the constraints of the standard setting and operating rule process? How do we make sure the operating rules process is entirely coordinated with the standard-setting process and other industry efforts in the space? How do we maintain a functioning feedback loop that encompasses this pilot testing, stakeholder surveying, focus groups and other appropriate mechanisms for ensuring that the standards and operating rules are indeed effective? How do we envision new issues on the horizon are considered and dealt with in a timely fashion?

How do we obtain appropriate funding to ensure that this process can be completed in the timeframes established under the ACA? When and how do we obtain and incorporate the feedback from the entire health care industry, from the solo practicing physician to the CEO of a Fortune 500 company, and then convey back to this full constituency the value of implementing each new set of standards and operating rules?

We believe that answers to these critical questions merit a serious commitment of time and thought from the entire health care community. We strongly recommend that NCVHS host a two-day meeting targeted specifically at developing an optimal workflow timeline and process to harmonize all the standards and operating rules update pieces from change order management through pilot testing, final adoption and the ultimate deployment of each new set of standards and operating rules. We also urge the NCBHS to retain a facilitator with expertise in process evaluation and re-design to help the meeting participants in the refinement of the existing process necessary to respond to the shortened time frames and deadlines, including those associated with the addition of operating rules and that address the increasing pace of health care delivery transformation. The AMA looks forward to continuing to work collaboratively with NCVHS and the respective stakeholders to bring about administrative simplification for physicians and others in the industry. Thank you.

DR. WARREN: Our next speaker is Don Bechtel.

MR. BECHTEL: Members of the committee, good afternoon, I am Don Bechtel. I am a patient privacy officer for Seamans Medical Solutions USA, for their Health Services Division. I am also the current chair of the work group Electronic Data Interchange, and today I will be speaking on behalf of WEDI. I would like to thank you for the opportunity to present testimony today on behalf of WEDI, concerning the maintenance and modification process for standards in operating rules.

WEDI represents a broad industry perspective of providers, clearing houses, payers and vendors and other public and private organizations that partner together to collaborate on industry issues.

In consideration of the time available for my verbal remarks today, I will summarize our comments on concerns and current processes, and focus most of my time on our recommendations.

So summarizing our concerns and current processes, WEDI has identified several areas in the current standards development and adoption process, that add to the overall costs and implementation and reduce the effect of an –- standard.

The most critical concerns are as follows: The current process takes too long. Eleven years for 4010 to 5010. There are four parts to this process – the standards development process followed by the adoption process, then the systems readiness process and finally, implementation. Untested standards also contribute to the implementation problems with things like errata, and also, in my written remarks, we discuss approaches to how we might address doing the testing; one being a pilot approach, another being a test tool, something like the IHE tool, which might all help to – the IHE tool might help to reduce the amount of time that you might have to experience with a pilot.

Also the current process has multiple implementations; one, the current implementation of the standards and implementation specifications and then because of some problems we found, we had some errata, which for some stakeholders, meant additional work and another implementation cycle for their software.

And then finally the operating rules that were mandated by legislation, making a third implementation, each of these requiring some development and an adoption process. Fourth, we have concerns with how TR2’s, an X12 document of technical report type 2, will be used as part of the operating rules. We don’t think that these should be ignored, but we don’t know that the current process would recognize them either, so we would like to be sure that these are considered when developing operating rules.

We also believe that a clear delineation between operating rules and the standards and their associated implementation specifications is needed. We are clearly lacking a definition on what operating rules can be. I think we’ve heard this from almost every presenter today.

And lastly, we have concerns that all stakeholders are not getting an equal voice in these organizations, and we believe that some sort of remedy is needed in this area.

So looking at our recommendations, WEDI recommends that the following measures be taken.

First, standards and operating rules should be developed in synchronization and collaboration, such that multiple implementations are avoided, and the standards implementation guides, the TR3s, incorporate and reflect the necessary business rules to the maximum extent possible. Standards and business operating rules should address distinctly different implementation objectives. They should not have conflicting implementation rules. As two separate items developed independently, they should be developed in collaborate fashion and made available as concurrently as possible. WEDI would be open to any other process improvements that would achieve this goal.

Two, guidelines must be developed to clearly distinguish what should be included in the standard versus what should be specified by an operating rule.

Three, before industry adoptions, standards must be tested to identify potential gaps and implementation issues. This will allow corrective actions to be taken before widespread implementation. This also implies that a given standard should not be considered as finalized until after the testing processing is completed. This approach will help to avoid the need for addenda and errata, and the same may be true for operating rules.

New versions of implementation specifications should not be finalized until the testing and validation can be completed. This will help avoid the perpetuation of gaps of issues from one version to a subsequent version. In conjunction with this, a more expedited change process must be implemented such that standards can be updated more frequently and in smaller increments. This will help to avoid the larger, more expensive upgrades that currently exist and will facilitate a more rapid incorporation of needed changes. This can be achieved with the ASC X12 process changes, but there must also be an improvement in the adoption process, to get us to a shorter, more frequent update cycle.

Perhaps more collaboration between the SDOs and OESS would allow earlier development of an MPRM or an interim final rule, to avoid the long delay between recommendations and the realization of a proposed or an interim final rule being published.

Five, all stakeholders, providers, payers and vendors must be involved in the standards testing process. We recognize the difficulty in gaining providers’ input as standards are developed, but the provider and the payer participation in the validation process will help uncover provider and payer-specific considerations that may have been missed during the developments of the standard or of the implementation specification. However, having the vendors involved in the pilot, or testing, process will ensure that they are doing the analysis and the application change as necessary to support the changes, which will also bring an opportunity to discover potential problems earlier in the process. This should reduce the need for errata being issued during an implementation process.

Vendors may also be reluctant to make the necessary system changes for draft standards, implementation specifications, that might never be adopted, and subsequent investments are costly and could prevent them from doing other work, hence some sort of incentive should be considered to gain their participation. Stakeholder organizations not participating in a pilot or in the testing process should at least be reviewing the work of the SDOs during their public commenting process.

Announcements in the Federal Register that such public comments are being requested by an SDO would be very helpful in getting more eyes on the work before its adoption.

Six, a quick fix mechanism must be developed in the event a gap in the implementation specified is identified once full-scale implementation is under way. The ASC X12 emergency fix process that was created at CMS’ request with 4010 should be utilized when there is a critical problem that might prevent implementation from occurring successfully, or to make quick adjustments to accommodate legislative mandates that were not anticipated. This needs to exist for operating rules as well.

Consolidated change logs should be available that include all changes from the prior adoptive version versus only those from the immediate prior version. It will avoid the need to piece together the complete picture of changes when an interim version of a standard was not adopted, the point being sometimes we skip a version, and in our implementation specifications we have change logs from the version we skipped, and then in the version we get to, we have change logs for what happened between that one and the latest, so nothing gets the whole picture, and we need to have that.

Actually, X12 does offer that at least for 5010; they did offer that through their publisher at added cost.

In conclusion, WEDI supports the need to review the current processes and enhance them to provide for timelier coordinated updates of standards and associated operating rules, to minimize the post-implementation issues with an adopted standard. We also want to emphasize the need for SDOs and the operating rules entities to work together in close collaboration to avoid conflicts and ensure successful implementations and more industry consistency.

WEDI thanks the sub-committee for the opportunity to testify and we offer our continuing support in enhancing this process. Thank you very much.

DR. WARREN: It’s late in the day, Don. Okay, our next speaker is Richard Donoghue. Are you on the phone?

MR. DONOGHUE: I am. My name is Richard Donoghue, I’m the Senior Vice President for Strategy Planning and Business Development at NYU Langone Medical Center in New York. I’m also Chair of the Linksys Board of Directors and I’m speaking to you today as the Chair of the Linksys Board of Directors.

Linksys is a not-for-profit organization that is e4qually directed by participating providers and health plans, and our mission was to simplify and reduce the costs associated with administering health care plan payments. I thank you for the opportunity to speak with you again today, and I know it is very late in the day, and I will try to keep my comments short.

On July 20, Eric Wallace, who is the Linksys Executive Director, and I, testified at your hearing concerning the operating rules for eligibility and claims status. We offered the Committee specific recommendations on how to proceed with new regulations, and we also suggested some short and long-term tracks to maintain progress and to move to a single process that would include a national strategy, policy direction and certification, driven by an equal partnership of providers and plans.

We had presented an overview at the time of a 5050 provider plan entity steering committee that would provide information in to the DSMOs as well as the SMOs. Your decision last fall to designate CAQH Core to develop the operating rules required that they change their governing structure to include provider representation, we viewed as a very positive step. We were sufficiently encouraged by your conclusions that we took the following steps.

The six major academic medical centers in the New York area that were the provider components of Linksys have become members of Core, with commitments to become Level 1 and Level 2 certified. All providers, all six, are now active participants in the Core workgroups. Based upon our recommendations, the New York E Health Collaborative, which is a statewide public-private partnership that seeks to define a roadmap for New York State to advance health information technology, is considering requiring Core certification for all health solution vendors and all health plans related to administrative information, and lastly, we have begun the process to liquidate Linksys so that our members can become more active participants in Core, and the NYSE, the New York State collaborative initiatives, rather than continuing to pursue just a small New York State-wide set of activities.

We do appreciate the comments made by the previous speaker from the State of Washington about how statewide efforts can create effective learning labs that more quickly get to some of our solutions, and we think there may be a role for that, and we encourage you to consider those kind of things. We certainly agree with all of the presenters on shorter cycles that would be helpful, and the presentations have certainly made it clear as to the cumbersome nature of this process, and while we encourage you to look at all of those things, we also believe that we can benefit from taking a step back. The six providers that are now going to be working very closely with Core, we expect to see some benefits as a result of those activities, but we think they are going to be rather small in comparison to the potential for administrative simplification that we believe today’s technologies, with proper harnessing, can deliver.

The streamlining that was anticipated by the electronic transaction sets framed at HIPPA fifteen years ago have clearly not been realized, and much of the testimony today has spoken to that. However, most of the activities that we have heard are all related to the way in which we might shorten and change the cycle for incremental change, and we don’t believe that incremental change is going to give us the true promise of administrative simplification.

We do believe that what we first need to do are in parallel to the efforts to simplify the process. We could benefit substantially by a payer/provider visioning that would establish a set of goals for what we could and should be able to achieve, with today’s technology, in the form of these health care claim transactions, as well as the way in which it can connect to the clinical information, but that until we do that kind of visioning and then establish project groups that are set to achieve that vision, we’re only going to get the incremental change that we’ve gotten over the last couple of years, and it will take as long as it’s taken over these many, many years, so while we’re encouraged by Monday’s announcement by CAQH Core of transition committees to change their governing structure and while we encourage the NCVHS to continue to pursue some of the simplification spoken to by the previous speakers, we strongly encourage that there be a process created to set up a vision for the future and then work groups to get us there.

I thank you for your time.

DR. WARREN: Thank you. Stacy, are you still on the phone? We’ve got about five to ten minutes, so if you’re still willing to go on if we have time, go ahead.

MS. BARBER: I’ve already presented earlier; I didn’t know that I had anything else to do.

DR. WARREN: Okay – we’ve got you down twice, that’s why. We just had you down twice on our list of speakers.

MS. BARBER: Yes, we rolled everything up into the one testimony.

Agenda Item: Questions by the Subcommittee

DR. WARREN: Okay, so I’ll open it up to questions from the Committee and staff?

MR. SORACE: I was curious more about the certification that the last speaker and –- heard from Core in the last panel, a bunch of very basic questions. What’s the business model? Who does it certify – the payers, the providers, intermediaries? Is it all or nothing, or is it broken up in some ways? And just sort of a very general idea as to how it functions.

MS. LOHSE: For those of you on the phone, this is Gwen Lohse, from CAQG CORE. Just a quick overview with regard to that question. The certification for the Core operating rules applies to health plans, vendors, whether it’s a payer-facing vendor or a provider-facing vendor, because they’re obviously very different, and then large providers, because some large providers have home-grown systems and therefore they’re not relying upon their vendor; they’re like the EHR. You think about meaningful use; they had homegrown systems as well as vendor systems that were commercial.

The way in which it works is for every single Core operating rule, whether it’s response time, data content, acknowledgements, companion guides, SOAP and web services, digital certificates, the whole list of items that it may be that there is a test that that entity needs to undergo for their role in the particular requirements. So based on their role, if they’re supposed to send the acknowledgment through, they get tested that they’ve done that. If they’re supposed to deliver year-to-date deductibles in and out of networks, they’re supposed to do that. If they’re going to complete a companion guide and the flow and format, they have to show the actual companion guide, that they’ve changed it and it matches the flow and format.

There’s an independent – Core issued an RFP, and I think Tammy, actually was at the meeting where we did an RFP, asked vendors to respond and had them create business models for doing the testing, because we did not have the dollars for them to build against the test scripts? And we had three responses. One of the companies was not accepted by the Committee. There was a mix of health plans and payers at this meeting, and two of them were, and then the one that is doing the majority of the testing offers the testing for free. We tried to do the majority of the testing on line, and that company is called EdFX, and they need to exactly follow the test scripts by rule, and then there is a set of master test bed data, so EdFX can simulate the role; if you’re testing a vendor, you can simulate that you’re a provider testing the vendor, or you can simulate if you’re testing a health plan that you’re a provider testing a health plan.

MR. SORACE: And how long is certification good for?

MS. LOHSE: Certification is good for an ongoing, for Core Phase 1, you get certified once, and then you maintain, understanding you’ve signed a number of documents to maintain HIPPA compliance and doing some other things. There’s a process in which enforcement occurs, so if someone says that you’re Core certified, you’re showing the seal. Once you’re Core certified, if you’re Mayo Clinic or you’re Aetna, you need to share that information with all your trading partners, not just some of them, every single one.

So for instance, SOAP and web services, if someone asks for it, it’s a safe harbor, you need to offer it out, and you’ve been tested against it, EdFX, make sure you can actually test and connect that way.

So it lasts for as long as, for you to go to the next stage, and then you get a new seal for the next phase of the rules.

MR. SORACE: So next version –

MS. LOHSE: Exactly, because all the rules build off of each other. The testing also has a – because it’s on line, it’s private between the entities going through it and the actual testing vendor, so they could fail 30 or 40 times. Some people fail until they get it right and some people have done a lot of project planning beforehand and they do it once or twice and they’re done, so the time frame could be anywhere from four to six months to a year and a half, depending upon what the gap analysis is, and we have gap analysis tools, about where you are now as an organization between the rules and where you need to get to, to finish the rules. And there’s a pretty wide variation, because the rules cover both data content as well as infrastructure, and some organizations are much more focused on the data content, some are much more focused on the infrastructure and some have really just done the bare minimum, so I would love to give you an average time frame, but it’s pretty tough.

And we have done a bunch of public webinars with WEDI, for instance. We have done, they’re free of charge for the ones we’ve done with EdFX, and we’ve done a few with the AMA, and then submitted letters when meaningful use was coming out, submitting letters to say what are the lessons learned within the Core certification process.

MR. SORACE: So two factual questions, really, briefly – how many people are certified on which side, so how many payers and how many vendor facing payers and payer facing vendors – how many people have been certified and in which direction are they sort of going in?

DR. LOHSE: Great question. For the payers themselves, I know the payers represent, those that are certified, represent about 130 million lives. So it represents about half of the commercially-insured lives, and those participating in Core represent 75 percent of the commercially insured lives, so you’ve got 75 percent –

MR. SORACE: You have two-thirds –

MS. LOHSE: Two-thirds, yes. For the vendor systems, I can give you the list. We all know it’s difficult to say how many providers or how many payers a vendor represents, but it’s a mix of the centricities of the world, that work with the large hospitals, to the vendors that work with the individual docs.

And then for the providers, you have a number of large hospitals like Mayo, the VA was a government entity but from the provider side, Montefiore is certified or 1 and they’re going through 2, and they’re just about done. A few others – Wake Forest – I can share the list with you. Hopefully that was a good overview.

But it’s been a process where the entities have really embraced the lessons learned, that they go with their trading partners because in many cases, for instance, Mayo, if you don’t mind me pointing out you, they really had to collaborate with – they had in-house services and then they worked with a vendor which will remain nameless, because it’s your business to share, and they had to really collaborate working with that vendor, how to get their certification done, because some of the things were done within Mayo and some needed to be changes their vendor had to make.

DR. WARREN: Is that all? Denise?

MS. BUENNING: This is really kind of directed towards Don, but I think I also heard I earlier in this afternoon’s testimony. The talk about testing and piloting some of these standards, kind of doing a test drive on it before it actually gets into production or into use past a compliance deadline, in terms of pilots, in my e-prescribing days we did a number of different pilots to test the e-prescribing standards, and even when there was money available, we had a very difficult time recruiting companies to get involved just because, again, everybody’s trying to conduct business at the same time and it’s difficult to try and get them to focus on something that may or quite frankly, may not, work.

So in terms of piloting some of these standards, is it your intention to kind of pay me now or pay me later sort of thing? In other words, try and get the glitches out up front as opposed to having to deal with perhaps an errata version afterwards? Is that the intent of the piloting, and if this is something that the industry is interested in, what can industry bring to the table in terms of taking it on and perhaps forming some kind of a work group or something to really work out how that would all come about?

MR. BECHTEL: In my written testimony, I do elaborate on this a little more. Doing a pilot, as you said, is very complicated and not many people are ready to step up to that. But we did have a WEDI pilot for claim attachments; in fact, there were two of them that were very successful, and we learned a lot from that process. It also takes a lot of time, and it requires a commitment from a vendor. In the case with claim attachments, we weren’t making a lot of system adjustments; we weren’t making system changes. We were adding on to things we already did. With our other standards, it would probably being more complicated to find vendors, mostly vendors, willing to step out to do that.

And that was why I sort of said that maybe we need to think about a test tool, because that might be more effective. And the IHE test tool was an example where we could have a few vendors and a few health plans and providers – actually just the vendors; you don’t even need to have the providers participate, per se.

Illustrate that they can do the exchange between a provider, maybe a clearinghouse and payer, can all be in that IHE model, and exchange the data and do the work they need to do with the data that they’re getting. I think that’s a more practical approach where we don’t have to interrupt regular processing, but it still requires a commitment from the vendors to be willing to make those changes to put in that environment. But I think that’s a little more achievable, and if there were some incentives to get the vendor community to kind of step out in front and do that work, I think that would be achievable.

If we had some guarantee that the work was going to go forward, that they weren’t making an investment to prove something and then nothing ever happens – as soon as you do that you’re going to lose interest. If the work gets done and we learn from it and we implement, I think that would be more successful.

DR. WARREN: Raj, are you still on the phone? OK, Walter.

DR. SUAREZ: Thank you. Again, thank you for the testimony. I’ve come out of this particular session and throughout the afternoon with basically the following, but it stems from the industry – it’s not like the industry is clamoring for revisiting and finding a much more streamlined, more efficient way of developing and adopting standards. And by standards, I mean the three things – standards, implementations, specifications and operating rules.

I was just thinking that we need at least five or so things, and I wanted to validate those with all of you. We need to establish, first of all, a set of guiding principles, and I think a couple of testimonies pointed to some of the questions, and Tammy, I think your set of questions here, what are the optimal places, how do we make sure the issues of high priority and –- are addressed. These are the kind of guiding principles we need to define first to come up with this new approach to standards development and adoption process.

By that, I don’t mean we’re going to look for revamping at all – of course the internal process that each of the SBO’s are going through, but more how those processes are harmonized externally, withal the other SBOs, with the operating rule authoring organizations, with the data content and code maintenance organizations, to have a much more organized and sort of defined process into the future that has set dates and expectations, not just waiting for when someone is going to request something.

So need to establish these guiding principles. The second thing is we need to clearly delineate the differences and the relationships between operating rules and standards, and this is something that has come up consistently, and of course educate industry and put as many information items, even FAQs and other things, that help clarify – is this supposed to be an operating rule or standard, and who is responsible for those.

We also need to create a place; I think we heard three or four times today that we need a place where all the groups – and it’s not just the DSMO members, the operating rules, authorizing organizations, but also vocabulary maintenance organizations and others come together to agree on these sort of sequential processes and an orderly process.

We need to define this new process, which establishes sort of the steps and the delineation of roles and responsibilities, and then finally, we definitely need a defined timeline in terms of when to expect these new requirements to be adopted, and Tammy again, and others, have presented incredible pictures of how complex, first of all, this is – how difficult for organizations like each of the ones we represent and we are employed by, that have to participate in all these places and all these – and pay the dues and have volunteers to put time in developing them – so we need to define dates and recommend dates of when things can be expected to be adopted, and I’m glad to hear, of course, that there is work toward establishing a two-year cycle, let’s say starting with X12’s own cycle, on the development of standards, so that perhaps we can define specifically when to expect these sort of new versions to come.

As I think Greg mentioned, there is a possibility, certainly, that in some transactions, there’s no need to move to the next version because there isn’t enough business reason to move there, so not necessarily everything will move to the new version, but based on business decisions.

So I just wanted to sort of validate that those five elements; again, guiding principles, distinguishing and establishing the relation between operating rules and standards, creating a place, defining a new process and establishing this defined timeline; is that kind of the five, or are there other things, or are there things that are not in the list or should be different?

MS. BANKS: I would definitely encourage the learning laboratory, to make sure that the continuous quality improvement is used for these standards through the whole process so it meets the business need instead of the shortened cycle by itself.

DR. WARREN: Does that include testing as well, or just learning?

MS. BANKS: I don’t know if Donoghue is on the phone with – I mean, Linksys did a beautiful model of a learning laboratory and was able to feed the deficiencies of where it didn’t meet the business case. Something like that, we are too far down the road and we have too much cost, there being ways to not to clearly articulate what the need is and to figure out how it can be fixed.

MR. DONOGHUE: This is Richard Donoghue; I agree. I think it was a very successful approach. I have had some conversations with some of the major payers. The New York E Health Collaborative is very interested in even helping finance part of such a learning lab. And the New York E Health Collaborative is also working with comparable agencies from 20 states throughout the country, and they’re all trying to think about ways in which we can get some focused efforts, where different activities in different states can all be working on a problem that brings together a national solution.

DR. SUAREZ: I just wanted to see if Greg or Laurie or Don had any thought about this list; is there anything outside of those five or six things that you thought would be necessary to take us, sort of, to the next level of these? Anything that is missing?

MR. FISHER: Just maybe some clarification again; Don mentioned kind of peripherally. There’s no economic incentive just to do testing. So what we really need to do is to have an organized, as you said, organized defined timeline, but that really has to be inviolate, because once you extend the timeline or skip a version, then all this voluntary testing and voluntary participation in the standards process goes away, so it’s got to be very strict. And you may want to consider if the regulation or if the –- things can be changed to allow production adoption of a next version.

The pilot is talking about test versions, but if you allow a production version that involves some amount of incentive, because if there’s a benefit to that transaction, then those two parties can benefit somehow through that production version, so consider that as well as an incentive.

MS. BANKS: I just wanted to clarify, when I was talking about a learning lab, not only testing, but end-to-end testing, so you can also determine the return on investment, because why in the world do I want to get a new vendor if it’s not going to meet my business needs, so we need to be able to document why and where the cost is. Again, I’m coming from a physician perspective, but I would assume the payer also wants to know what is the ROI coming back when I implement this new version?

MS. WILLIAMSON: My question relates to the issue of versioning as well. It’s the comment that Greg Fisher made and Watler just brought up about allowing some transactions to stay in an older version. It made me thing about the earlier testimony from Lisa Miller, when she was talking about the acknowledgments and had said the 60/20 acknowledgments could be used with the 50/10 transaction. So my question is, do we need to, considering the process is slow, we’ve heard that. Is it essential to do a sweep of the same version always, or can we reap the benefits of different transactions at different version levels?

MS. WEIKER: Hi, Margaret Weiker. Years ago when we looked at 5010 and 4050, which was the version – we had 4010 and we looked to do 4050, and then 5010, so as we were doing that, there were some transactions that didn’t have a lot of changes made to them, and X12 said okay, if we adopt the 837 and 5010, but we leave the 834 at 4010, is that okay? And the answer we got was no, that you needed to move them as a set.

Now that was years ago; maybe things have changed since then with vendors and a better understanding and more open source type of coding, but back then, when we were looking to that movement, it was a flat out no, we want them as the same version.

DR. WARREN: Who said that vendors –

MS. WEIKER: No, the vendors, payers, the industry.

In fact, it was testimony here that we also gathered that said – it was before your time Judy – and I was very young back then, but back here it was like no, no, we want them as a group, we want them as a suite, so to speak, and not individually.

DR. WARREN: Is that enough? Jim?

MR. SORACE: I’m having a case of brain freeze – I’m trying to figure out; in NCPDP and in the e-prescription world, people can be early adopters of vendors, I believe, and they can adopt versions ahead of formal approval. Is that not the case for the X12 and for the other HIPPA transactions? In other words, is that a regulatory issue or is that a –

MS. WEIKER: Okay, when you look at the E prescribing environment, and you look at where that started, that wasn’t a mandate by regulation. Originally, E prescribing started years ago with several companies that actually created the standard among themselves, then brought it to a standards organization and said hey, look, this is great, this is what we learn, made it a standard, we had industry adopt it, MMA happened. At that point they said here’s the functionality and because we are under the impression that you have to name a specific version in regulation, that therefore you can do a script 8.2, or script 10.6, but it’s still a specific version that’s mandated.

Today, in regard to e-prescribing, just like HIPPA’s mandated today, but there’s still standards that you can use and implement that aren’t HIPPA-mandated, that have a lot of return on investment when you look at them, but they aren’t HIPPA-mandated, and you typically go back to pre-HIPPA, where there was a business need to implement a certain functionality and that was done without it being mandated, and then I can move to another version if all of my trading partners agree with that.

DR. SUAREZ: But to maybe to answer or to expand on your answer, Margaret, can an entity implement 6020, 835 today? No. The only one that is permitted today, this year is 4010, and 5010 during this transition year. Starting January 1, only 5010, no 4010, but no 6010, 6020, 6050, none of the future ones, until there is a rule that says you can do 6020.

Now there could be a rule that says you can do 6020 for two years along with 5010, as a transition. Those kinds of things could be done but then that’s part of what maybe had been suggested in some of the testimony, but as of today, there is that requirement. In fact, it’s so much so that in the coding inside, it’s even worse. On September 30 of 2012, you must do ICD 9. On October 1 of 2013 you must do ICD 10. You can do ICD 9 the day before, I mean the day after. So it’s more strict, so that is what we have today in the regulation.

DR. WARREN: I think that was one of the issues I was pleased to see in the ACA bill, was going to interim kind of rulemaking instead of –- first, and I think that was in results, some of the recommendations this committee wrote to speed up standards and –, because of these issues. So we’re still looking for ways to speed it up.

MS. WEIKER: I agree. And so are we. And keep in mind, Lisa’s comments were made around the acknowledgement piece and the control structures around that, and not to the existing HIPPA-mandated transactions.

MS. WILLIAMSON: And that’s really where I was trying to put my focus, was on those. It just felt like why should we, when Lisa mentioned the things that were accommodated in the 6020 for the acknowledgment, why would we select 5010; do we have to take the 5010 for acknowledgments when we could do 6020 and get the benefits?

MS. MILLER: This is Lisa Miller. It would actually be the control segments, those envelopes, and it was the envelope that we changed that gave the ability to use the acknowledgment, the TA1, differently. And the way I described this is, everybody loves Jello, right? And it has its base foundation; it’s a functional group. And then you add flavor crystals and you get cherry and you get grape. Well that’s kind of what a functional group is. I have a flavor crystal that says whether it’s –- 37P and it’s a 5010, but those envelopes, when FedEx comes out and they have a new envelope, they hand it to you and it’s pretty and it’s got new colors, but you can still use the old one. Well the new envelope structure is what would let you have the new functionality. Those control segments do not have to be the same as the standard you implement in the version. That’s a real difficult concept, because vendors would have to move forward, so it’s not like taking the whole suite; does that make sense? Okay. And I do use the Jello analogy –

Agenda Item: Concluding comments and next steps

DR. WARREN: Any other questions? We’ve already kind of summarized where we were today, so anyone want to make any more observations?

DR.SUAREZ: Well first of all, again, to both our presenters this morning and this afternoon, on behalf of the Committee and the sub-Committee, thank you. It’s so impressive to see how much thought you have put into all these recommendations, and to take the time to come to attend, to participate in this, we are very much in appreciation of that.

Again, to our Committees staff and sub-Committee staff for helping us put together this very, very insightful hearing. Probably at some point, in one of the testimonies we were hearing, the acknowledgments transaction maybe had been requested for what is it, 20 some years now, since 1993 or something like that, we heard it – but we are very pleased that we were able to convene this hearing and bring it up and begin to think about the selection and adoption of those standards.

And of course, during the afternoon, with this hearing on process improvement for the standards process and the operating rules, I think this has really elevated our challenge as a sub-committee to come up with an approach, and we’re going to certainly continue to call upon your expertise and your involvement in helping us develop the recommendations of this new process, and clearly again, the message, as I mentioned, has been that the current process is confusing, it’s complex, it’s costly, and we need to find a better, more efficient and more effective way to achieve the goals that we are looking for, which is the benefits of administrative –- of the standardization, of business process improvement and all that is only achievable if we have efficient ways to move quickly to new versions of the standards and improve those business processes.

I think, in terms of the next step, we’re going to be working on certainly a letter from the sub-Committee and it will go through the Committee approval process, to the Secretary, on the acknowledgments side, and we’re –- to try to bring this up at the June meeting of our committee, which is the next full committee meeting, June 15 and 16. We are going to certainly be working through the testimony from this afternoon, and coming up with sort of an assembled set of observations and we hope what would be recommendations around this process improvement.

Certainly, there have been calls for having NCVHS convene additional meetings, a two-day meeting or other meetings, to try to facilitate this debate and discussion, this definition of this new process, and so we’ll be looking at how to achieve that as well.

With that, I think I’m going to turn it to my co-chair for some closing remarks.

DR. WARREN: So closing remarks will be very erudite – apologize, go out and play well with each other and have a lovely afternoon, and we’ll adjourn the meeting. Thank you, everybody.

(Whereupon, the meeting adjourned.)