[This Transcript is Unedited]
Holiday Inn Rosslyn at Key Bridge Hotel
1900 N. Fort Meyer Drive
Arlington, Virginia
Agenda Item: Welcome and Introductions
DR. SAUREZ: Welcome everyone. This is the National Committee on Vital and Health Statistics Subcommittee on Standards. This is the first in a series of three hearings that we're going to have today and tomorrow. My name is Walter Suarez. I'm with Kaiser Permanente, a member of the Committee, co-chair of the Standards Subcommittee and a member of the Population Health and the Privacy and Security Subcommittees.
I don't have any conflict. I do want to express that my organization is a member of several SDOs including HL7 and X12, whom we will hear from. We're also members of WEDI, and members of several other organizations, but I do not see those as any conflict, but I just wanted to mention that.
We're going to go around and do introductions for the members of the committee, if you could express whether you do have or not a conflict. We'll also go to the phone in a minute, to introduce any members of the committee that are on the phone. Then we'll get started.
DR. WARREN: I'm Judy Warren from University of Kansas School of Nursing, member of the Full Committee and co-chair of the Standards Subcommittee. In light of Walter's disclosure, I don't have any conflicts, but I am a member of HL7, but not appointed to any of their committees or chairs or any leadership position.
MS. DOO: I'm Lorraine Doo with Office of E-Health Standards and Services at CMS. I also am a member of HL7 and co-chair of the Personal Health Record Functional Model Workgroup. No conflicts.
DR. KLOSS: I'm Linda Kloss, a health information management professional. I am a member of the Full Committee, co-chair of the Privacy Subcommittee and a corresponding member of the Standards Subcommittee. No conflicts.
DR. CHANDERRAJ: I'm Raj Chanderraj, practicing cardiologist. No conflicts.
DR. FITZMAURICE: Michael Fitzmaurice, Agency for Healthcare Research and Quality, arch liaison to the National Committee. I'm a member of HL7's Advisory Council.
MS. MEISNER: I'm Deborah Meisner representing Emdeon. I'm also on the WEDI board and am the co-chair of the X12 Healthcare Task Group. No conflicts.
MS. STAHLECKER: Chris Stahlecker. I'm with the Centers for Medicare and Medicaid Services and Medicare fee-for-service only. I'll be happy to address the committee later.
MS. KOCHER: Gail Kocher, Blue Cross and Blue Shield Association.
DR. FRIDSMA: I'm Doug Fridsma. I'm the director of the Office of Operability and Standards from the Office of the National Coordinator for Health Information Technology and the acting director of the Office of the Chief Scientist.
DR. RISHEL: I'm Wes Rishel, employed by Gartner, former member of the boards of HL7, WEDI and HIMSS. I'm a speaker here today.
MR. TENNANT: Rob Tennant with the Medical Group Management Association. No conflicts.
MR. BARBOUR: Robert Barbour, American Medical Association, senior policy analyst. No conflicts.
MS. DARST: I'm Laurie Darst, revenue cycle regulatory advisor at Mayo Clinic.
MS. BURCKHARDT: I'm Laurie Burckhardt, WPS Health Insurance, EDI manager.
MS. COMBS-DYER: I'm Melanie Combs-Dyer. I'm the deputy director of the Provider Compliance Group at CMS.
MR. MILLER: I'm Craig Miller. I'm here on behalf of the Office of the National Coordinator where I'm a program advisor for the federal health architecture employed by Vangent, a general dynamics company, as the vice president of health strategy and innovation.
MR. SORACE: I'm Jim Sorace with ASPE. I'm a staff to the Standards Subcommittee.
DR. SCANLON: Bill Scanlon, National Health Policy Forum, member of the Committee and of the Subcommittee. No conflicts.
MS. GREENBERG: Marjorie Greenberg, the executive secretary of the National Committee from NCHS, CDC.
DR. SUAZREZ: Before we go any further, I just want to make sure if there is any body on the phone, any member or staff to the committee on the phone.
(No response)
MS. JACKSON: Debbie Jackson, National Center for Health Statistics, committee staff.
(Introductions around the room)
DR. SUAREZ: Thank you very much. The first thing I want to say, and make sure to acknowledge a number of people. First of all, Lorraine Doo for helping us coordinate, not just this hearing, but all the hearings. She's our lead staff to the Standards Subcommittee, and so we really want to say thank you, Lorraine, for taking the time to organize all this.
Secondly, we want to thank every one of you for attending, for taking the time to prepare your remarks. We know that this is a very important topic. It's the first hearing in probably what would be a couple of hearings in preparation for recommendations that will go to the Secretary with respect to the option of standards for claim attachments. We want to thank the other staff from NCHS and from the agencies for providing all their support in helping us coordinate the hearing.
We're going to go through a few presentations at the beginning. We're very time-constrained. We'll let Lorraine explain a little of the sequencing of announcements.
At the beginning we'll have two presentations from Wes and from Doug Fridsma. We'll have a few minutes for any questions that might exist from the committee. Then we'll start session one and we'll hear all the presenters. Then at the end we'll reserve time for questions from the subcommittee members.
Then we'll take a break and go to session two and do the same. We'll first hear the testimony, and then reserve time at the end for comments and questions from the subcommittee. Then certainly we'll reserve time at the end for any public comments. That's the basic logistics.
MS. DOO: (Administrative Remarks)
MS. GREENBERG: (Administrative Remarks)
DR. SUAREZ: We welcome Wes Rishel from Gartner. We very much appreciate you providing us with some historical perspective on claim attachments. I know you have been working on this for so many years. Hopefully this will be seen by you as a combination of big progress and a process to get us where we need to be.
Agenda Item: Historical Perspective on Claims Attachments, Wes Rishel
DR. RISHEL: I worked on this a long time ago. At the time I learned an awful lot about a topic that has been my favorite soapbox ever since, which is incremental interoperability. I'm going to talk about that today, and given the limited time, I'm not going to dilly-dally.
This is the timeline. The great thing about this slide is year by year you don't have to change it because it's a question mark at the top. Fundamentally HIPAA was enacted in 1996. When it was being prepared in 1994 and 1995, most transactions that were sent electronically were sent over modems. The web was an experimental thing being used at universities, and most people who had email -- and that was few -- had it in a company setting or a community bulletin board setting, rather than Internet email. I just say that to give a sense of how far the technology has moved while we've been waiting for the regulations.
Why did they write a claims attachment portion of the HIPAA law, because it's a significant cost burden. It was seen as a way to save money in the administration of healthcare so that that money could be used hopefully for care.
The problems associated with handling paper are on this slide. I don't think I need to repeat them. The data that I'm giving on this slide, is data we have been using in presentations on attachments for at least six or seven years, so presumably you can scale everything up at least by inflation in going forward.
As of 2003, Altary found a huge increase in the number of denials that were associated with claims attachments, whereas previously denials had been associated with coding errors or patient ID errors. It's great progress to get to the point where we could begin to deny on claims attachments.
As we worked through the time that the government so kindly allowed us to do a good job on claims attachment standards, we went through several approaches. The first approach was all structured data, that is an HL7 attachment going in an X12 envelope to go to a payer, basically looked like an HL7 lab message.
There were a bunch of advantages to structured data, among that the thought you could get to auto-adjudication, the thought that providers could clearly understand what they needed to send to payers in order to not have their claims suspended or denied based on what has been attached. Of course, back then in 1994, electronic health records were just around the corner, so we expected to have a lot of structured data available in order send.
The reality, as I got to learn, about the industry was that electronic health records were rare. Payers for the most part had a very limited ability to use structured data for auto-adjudication. If they got to the point where there was a need for an attachment, their ability to auto-adjudicate was very low.
To the extent it even existed potentially, it existed for specific claim types or specific carriers and specific claim types. For example, there's a certain dental procedure code where the only thing the attachment has to say is the depth of the pockets, and then it's approved or not approved based on that.
But for the most part payers were still relying on adjudicators looking at the contents of the claim and making a judgment, an adjudication, on that. Nonetheless, there was plenty of room to get immediate return on investment just by using electronics to save people, paper and postage. I have added procedure to that just so I could say four “Ps” in a row.
There's a future potential -- we're still at the point where it's future potential -- that some of that planned auto-adjudication could happen in an environment where the payers could rely on the data coming in structured form in order to make the investment in order to do the auto-adjudication. The potential for better medical management based on clinical data being sent in a way that it can be used. There's a lot that's happened in the area of quality not through the claims attachment, but through other forms of structured data being submitted by other routs.
What I became concerned about is what I call frozen interface syndrome. For those of you who aren't old like me, I'm going to tell you a story. In about 1989 the Internet was not the roaring success it was today, but people had already figured out that the standard had problems. Running out of Internet addresses was the biggest problem, but there were others. They designed a whole new Internet protocol, a whole suite of protocols. It was called the open systems interconnect stack. It was the OSI of ISO, the only palindromic standard we've ever had.
NATO agreed among all of the countries that they would stop using TCP/IP and start using OSI. Department of Defense put out a directive saying after a date certain, they'd stop buying TCP and only buy OSI. GM built a whole plant for a system based on it. It never happened. It was just too much trouble to change the Internet to get to all the improvements. They found other ways to do the job.
Trying to balance frozen interface syndrome against the problem of being able to serve people in the short time, and after time the second version of attachments we came up with an approach based on XML, based on a bunch of technologies that were new then that really allowed to variants of the claims attachment.
The human variant had structured data so that you could process the thing through your system, but the actual decision-making data could be structured or could be facts that could be a scanned image, could be almost anything. The point is it could get to the people, paper, postage and process quickly in terms of the things.
And yet for reasons I'll show because it had this variant, there was the opportunity to take a specific claim type, a specific payer and say we'll pay faster if you submit it this way, and thus have an incentive to change rather than a date certain. We have a lot of trouble with data certains on going to standards. This is a clever graphic that displays all that, but I'm short on time, so I'll move on. I've already said this about it gains the immediate benefits, and yet it allows people to move forward.
All of this potential still exists and still is available in the material that is submitted for standards. There is update work going. I know HL7 will testify more about their part of it later, but nonetheless, the potentially is there.
I would really like to suggest the NCVHS considers strongly the opportunity to one time do things where the basic standards work is a low-tech investment and the ability to continually profit by it comes incrementally over time at the business pace of the payers, as opposed to at a date certain that's got to work for a small town in Alabama and New York City at the same time.
Keep in mind that even today, even with all of the work that the National Coordinator and the Stimulus Act have engendered, not all the data in the electronic health record is structured. In fact, it's a continual struggle to get more structured over time. A lot of the times when you need a claims attachment, it's not because of the data that is structured; it's because you want to see the op note, it's because you want to see things that are in the thing.
The ability to jump the border between structured and unstructured continues to be important and will be for as long as I'm a member of the healthcare system. And of course, you're a member of the healthcare system until you die. Treat claims attachments as the leading edge of a whole bunch of interactions around clinical data across stakeholders. That is to say try to use a common approach rather than a different approach for this and a different approach for rack audit and on and on.
Where possible, latch onto other standards. Show early return on investment by focusing on PPP and P. Avoid frozen interface system and enable ongoing what have you done for me lately kind of ROI by allowing the decision to go to structured data, to be economic rather than regulatory.
Consider the iPad. We talked about email in 1994. The only place anybody saw an iPod was when somebody gave a report to Captain Kirk. Consider the speed at which technology advances and use the Internet-savvy formats to go forward. Thank you.
DR. SUAREZ: Thank you so much. Very brief, but great overview.
DR. WARREN: I've recently come aware there's already a lab coat that's been designed for an iPad pocket. It's out there. There are also antimicrobial sleeves to go on top of your iPad, so you can take them anywhere.
DR. RISHEL: Given the pace of development in the Internet world, I expect that by the time we leave today there will be an iPhone app with Elaine's drawings in them.
DR. SUAREZ: Our next presenter is Doug Fridsma from the Office of the National Coordinator.
Agenda Item: ONC Perspectives on Attachments and Clinical Messages, Doug Fridsma
DR. FRIDSMA: I'm delighted to be able to talk a little bit about some of the things we're doing at ONC and coordination that we have the folks at CMS and the others. I'm going to start with the bottom line up front. I'm going to talk about the key points.
It's very important -- and to leverage what Wes has said -- that we need to create a portfolio of consistent standardized building blocks. We need to make sure that we've got those building blocks that can be assembled to solve the problems that we've got now and build them incrementally over time as things change and we have the notion of substitute ability with those building blocks.
We need to have vocabularies and value sets. We need to have document and messaging standards. We need to have ways of transporting things. Then we need services that will help support and secure the information that flows.
Second, the Transitions of Care work that we've been doing in the ONC as part of Meaningful Use is an important starting point. We can talk a little bit about that. It's an HL7 standard that's gone through draft standard for testing and use. It's really kind of their first step at building the building blocks, if you will, for helping manage some of those transitions of care.
Medical documentation to support claims should be part of normal clinical documentation and exchange. If we create two separate systems, we will end up with getting low-quality data or duplication. Up until about a year and a half ago when I joined the ONC I was a practicing physician, and I know when I filled out those billing forms, I knew that the ICD-9 code for diabetes is 250.0, but I wouldn't necessarily go and learn a lot more about the additional detail because it was really hard to do and I knew that I would get paid with 250.0.
The thing is if I knew I had to use that information to make clinical choices, I would probably be much more detailed about that. So making sure that these two things are linked is critical to getting high-quality data. It needs to integrate into the workflow. If it becomes an add-on to the work that you do for taking care of patients, it's not going to have that quality.
We need to have consistent data collection and standardization for claims and for clinical documentation. That means that our vocabularies and value sets have to be consistent as well. We need to have composability, which means I should be able to take things that were collected as part of taking care of that patient and re-compose them, move them in different ways so that I can then support other things like quality reporting or claims attachments or the like. We need this notion of substitute ability or composability of the data that we've got.
We need to make sure that we've got transportation standards. These need to be separated from the other kinds of standards that we have because had we done this 25 years ago, we would have been using our CompuServe addresses or maybe our AOL account.
Nowadays we have a lot of other options, and so we need to separate them. But it's critical that we're using the same way to do things so that if you've got a different way to submit claims attachments than you do to communicate with your other providers that you share data with, it's going to be yet another thing for doctors to do, and that's going to be hard.
This is to echo sort of, what Wes has said, which is start simple, structure what is important, and build incrementally based on experience or based on the kind of business value that we have. Interoperability is a journey, not a destination. Sometimes I feel like I'm in the station wagon, I've got Congress in the back seat, and they keep saying when are we going to get there.
We are on a path to getting to a better place, and we're going to have to continue to work towards that. If we try to do it all in one fell swoop, we're not going to be able to get there. We have to start simple on the things that demonstrate value, structure what's important and not structure everything right up front, and then build incrementally as we have additional needs and uses that develop.
Finally, I think there is a role that we need to identify those organizations or SDOs or whatever it is that can coordinate both within federal agencies and between the federal and the private sector because that's going to be critical to make sure that we stay consistent as we go forward. We're not going to be able to do this once and then be done. It's going to be an ongoing process to make sure as technology changes and as our understanding of what's necessary for claims attachment we need to be able to incrementally grow with that.
As you know, Meaningful Use is one of the things that we work on at the Office of the National Coordinator. I think the thing that's important is that many of the things I've just said are critical to our success as well. We believe that to get people to Meaningful Use we need to start by getting people on that escalator. Then we need to incrementally increase their ability to exchange information. I like to say stage one is all about making it electronic. Stage two is about moving it. Stage three is about doing important and useful things with it.
We are already in stage one where we're trying to make it electronic. Now we're working on trying to make sure that we've got transportation standards and other ways to move it around. Then finally we need to start to demonstrate that clinical decision support, and other things can be used to support patient care.
Within my office there are three things that we do to help get us to that interoperability challenge. That is we enable people to come together to solve the common problems that they have in a shared way. We have a variety of programs that sort of bring people together. I'll talk a little bit about one that CMS and some of our colleagues in Melanie's group have been working on.
We then develop a portfolio because it's not a one-size-fits-all. We have different people who have different levels of sophistication, but we need a portfolio that contains vocabularies and packages and transport standards that can be a symbol to help us solve problems.
Finally, we run a certification program as well for electronic health records. That says that when I follow the standards, it means something because I passed the test and I demonstrated that I have additional value in the work that we do.
This is what I did this summer. We called it summer camp. Everybody got their friendship bracelets at the end of the summer camp. This just indicates the tremendous amount of work that's happened with the volunteers and the others that have been working within our organization.
The thing that's important here is that we have vocabularies and code sets. We developed projects that will help us structure our content. We developed some transport and security standards and services that would help support that as well. It's just important to recognize that we have initiatives going on in all of those areas because that's our portfolio. That's how we're going to put these pieces together and demonstrate that they work.
One of the initiatives was called Transitions of Care. What this was was an effort to take the standards for how clinicians describe their clinical information in terms of the information that another clinician might need and to standardize that in a way that took the best of two different worlds.
We had two standards, one called CCR and one called C32. What we did is we worked together to come up with something that had the best of both of those standards, the simplicity of CCR and the power of composability that the CDA and the C32 provided. The template at CDA creates a series of building blocks that can be assembled together to support different kinds of transitions of care.
You might have a demographics section and a past medical history section and a review of system section. Those things then can be assembled to support transitions out of an emergency room, to support clinicians' exchange for consultations, and potentially if you've got those building blocks things like claims attachments where you pull those pieces together and assemble them to support that.
We have just launched a new project. It's one of our most exciting. Melanie Combs-Dyer has been one of the principal leads here. This is the Electronic Submission of Medical Documentation. It's a project really that's trying to bring together those transport standards, those packages and those vocabularies in a real-world setting so that we can understand the best ways to do it iteratively, incrementally and focused on what we believe to be an important value that the project can bring.
All these things we're done going to what we call the Nationwide Health Information network. That is the services, standards and policies that allow us to use the Internet. What we are not trying to do is to create AOL where there's a single place that you can get all of your information. We know how well that turned out.
What we want is we want to create the foundational elements that allow something like eBay to exist with something like Amazon to exist with something like your financial bill payment online. We want to have all of the building blocks that we can assemble to do things that we can't even imagine right now in terms of being able to support patient care.
For an example we've got the Nationwide Health Information Network. There's something called the Blue Button, which is a download standard. That says you've got information on your machine that I want on mine. There's something called Direct, which says I have information on my machine that I want to send to you. We have another one called Exchange, which says I have a patient and I think you have information about this patient. Here's some identifying information about that patient. Tell me if you've got some documents that you can send.
As we think about those modules, Blue Button provides one mechanism, Direct provides another one, but they all can be built around the same kinds of clinical vocabularies and the same kinds of packages. It's important to note that we need all three of those because we don't all communicate with our families in the same way. We use Facebook and email and our cell phones and our landlines.
Something as complicated as healthcare, needs to have the right way of transporting the things that will allow us to be successful. But we don't want to have a whole host of different ways to do the same thing. If you want to be able to post pictures, there might be a better way to do that with Facebook. If you want to be able to send an email message, you'll want to use that particular protocol as well.
I've already talked about these things. These are the key points. Create a portfolio and create those layers between the kinds of standards that you produce so that you can assemble them together. Look at the stuff that's going on in clinical medicine like the Transitions of Care. Make it part of normal clinical operations to do the claims attachment because that's going to be critical to getting good valuable information that's accurate. Start simple, structure what's important and build incrementally and provide some mechanism for coordination because it's an ongoing process and a journey towards the interoperability that we'd like.
DR. SUAREZ: Thank you so much. That was a really great way to frame several of the important issues that we're going to be discussing on claim attachment. I think clearly one of our objectives has always been to make sure that there is a very strong alignment between the work that we do here on this committee and subcommittee with respect to all of the HIPAA requirements and the work that's being done under the Meaningful Use program. So having the opportunity to hear this and to see the potential places for alignment is very helpful.
DR. FITZMAURICE: I have a question for Doug Fridsma because I'm really impressed with the way you pulled together not only a lot of projects and a lot of volunteers, but you've gotten products from those projects. As I look across the panoply of the projects, is there a place that looks for harmonization of terminology across Meaningful Use, the Standards and Interoperability Framework, the FHA Direct and the NWN(?), so that the same vocabularies, the same codes are standards-based and they're consistent with the ONC or CMS adopted recommendations of the HIT Standards Committee for consistency of meaning?
DR. FRIDSMA: We have gotten recommendations from the HIT Standards Committee around particular sets of vocabularies to use for administrative transactions, for clinical information such as problem lists, medications and laboratory test results. We are working with the National Library of Medicine to figure out is there a 90/10 subset that covers all of the major things that we'd like to take a look at. Primary care, transitions of care, maybe some public health reporting, quality measures -- those are all important, and identify what that subset would be, and then focus on making sure that we've got good mappings, that we've got good tools and other things around those subsets to make people successful.
It's a daunting task. ICD-10 is a daunting task that people are working on. If there are ways that we can shrink that change by making it easier for them, taking a look at where the areas are to focus on and mapping tools that might help them. Those are the kinds of conversations that we're having with National Library of Medicine and others to try to identify those things.
DR. SUAREZ: We are going to move onto the first session of our testimonies. We're going to hear first from provider perspective. We're going to hear first from Rob and Robert. Then we'll hear from Ruth and from the VA. Then we'll go to the payer perspective.
SESSION I: Current Business Practices in Claim Attachments: Priority Attachments, Business Practices, Mechanisms for Request and Submission, Other
Agenda Item: Provider Perspective, Robert Barbour and Rob Tennant
MR. BARBOUR: Robert and I are very pleased to be here to talk about this issue. With an eye on Lorraine and the heavy hand of government I'm going to move ahead to pass on on the current environment because I think Wes did a great job of that and talk about some of the recent research that we've done. I just want to relate when we put this survey out to our members, I got an email back from one and I'm sure it was a typo. They said I thought this was already completed. I thought it was part of HIPAA, the act from 1896.
What I want to do is give you a little glimpse into the reality of practices today. You can see here we've asked the question what types of transactions are requiring claim attachments. You can see here for claims 47.5 percent of our guys are saying often. We're obviously getting a lot of these coming forward. Referrals and workers' comp again very high.
The big question is how do they get the information to the payers? You can see here it's snail mail. That's what's costing so much money in the industry today. Even if you're sending an electronic claim, you've got to follow it up with manual processes.
I was talking to my brother-in-law who's a family doc just up the road here. He'll say that they have no idea what the health plan is asking. They just stuff a FedEx envelope with the medical record, send it off and hope for the best. That costs everybody money. It certainly costs him money, but it also costs the payers money because they've got to have somebody to wander through all this information.
How do the plans send requests to the practices? Again, you can see most likely it's going to be snail mail. They do occasionally send faxes and things like that. But this is all part of the process that is driving up costs in the industry.
What are the issues when it comes to receiving a request from the plan by mail? The question is they never received it, so it goes to the wrong address, it's sent somewhere else, it's seen as junk mail and it's thrown in the garbage. As well, for a large institution sometimes trying to route that mail to the right person so they can associate with a claim is also a challenge. As I say here, it can add days, weeks, even months to the claim adjudication process.
We also asked the question if there was an unsolicited option available, what percentage of claims would you exercise that with? You can see here a handful say, all of the claims. But you can see a large percentage are saying half, maybe a quarter of the claims they would send an unsolicited attachment along with it because they know that they plans are asking for that information.
The plan may take some time to have first pass at the claim and then get back to the practice. They know that. They've been in the business long enough to know when the plan requires this additional information. You can see here they would love to be able to preempt that, send along an attachment and speed up the process.
What's the value to the unsolicited? I know that's been one of the key issues creating a lot of angst within the industry. This is the reason why perhaps we never did get a final rule. But there's no question that if the provider knows that the payer requires additional information, it allows them to capture that data early in the process preferably when they're seeing the patient, but at least when they're working on the claim. And it allows the plan to get less information in the door that the information they need to be able to adjudicate the claim and decrease medical review time.
We asked them about the business rules because that's part of this process. How can we move ahead with Operating rules? You can see here very important is identification of the health plan, identification of the claim, minimum time required to adjudicate once the attachment is received by the plan, consistent format and consistent transmission standards. All of them garnered a very important rating.
The question is are there any savings that we can attach to this transaction? We asked them to try to estimate what is the cost to the practice? The average cost for a single attachment is $21.34. What does that translate to?
According to the 2005 proposed rule, between 414 million and 538 million attachments are to be sent in 2011. Who knows if that's accurate, but if it's even close, we're looking at billions of dollars of cost to this system that really could be weeded about by moving more to electronic. And another 100 million-plus are sent through hospitals.
We know all about the benefits. Predictability, lower cost for payers, clearly somebody's got to review all this information and that takes time. I think there are savings on both sides. With that, I'm going to turn it over to Robert.
MR. TENNANT: I apologize for starting out with the negative, but for those of you who know me, I always ask what's the downstream impact of all the good things we try to do? This particular transaction has some potential that we'd like to bring to your attention and ask that you address that potential in any of the recommendations that you give.
Interestingly enough, the concern I had I discovered in preparing for this presentation that in 2003 the AMA also identified a growth in the request that the transaction might open up as an unintended consequence of a good transaction. If we go back to the other slide that we saw on what it costs to do it, any growth in that number is going to create an economic burden and hardship for those providing the information.
What our concern is is that when we take a look at what's going on today in the industry as indicators that these things will grow, the first thing we looked at is the unintended consequence of this EsMD technology, which is going to make it really easy for transactions to be requested and turned in, which means it's going to be easy to ask for them. We think that alone is going to increase it logarithmically.
When we look at the pressure the payers are under -- and the AMA talks very closely with payers -- we hear that the payers, even the ones that have backed off a lot on asking for prior auths are all coming back to the table asking for more again because they need to get the good partners in the cost containment process of trying to control costs. We see a huge increase in prior authorizations, which means there's going to be a huge increase in attachments coming to support them.
Finally, what I believe will dwarf all the buy-in we're seeing here is claims attachments used for audit purposes. I attended a meeting earlier this week on the all-payer claims database. That is going to be a treasure trove for states and others to do a lot of data mining. It's going to open up opportunities to again start asking for additional information.
Our request is that we've got to have some limits. Practical limits need to be put on them, whether it's just in the ordinary course of events of asking for documentation to see whether or not a claim should be paid. You can't just keep asking them over and over again. There has to be a timeframe within which you can ask for them, etc. Some discussion has to occur to put practical limits on the requests.
Although I talked about the negative, I also want to take the opportunity to talk about the positive. I was at a very large academic medical center and raised my hand when the Medicare people asked if there were volunteers to test it. I twisted the arm of that medical center to be a pilot. We learned a lot.
My bottom line takeaway as someone who's used it is this is good, but the strange piece of it is there's another lesson learned for NCVHS in it for me. That is the full value of what it can do well for providers is to capture the fact that they've been asked for something to return, trace the fact that they got the request and they sent it to the right person within the organization, that they actually found it, sent it back.
The only way that's going to happen is if the vendor steps up to the table and creates it. The vendor industry is the missing link in all of the transactions. I heard you mention it this morning. I can't overemphasize how important it is to get the vendors at the table and get them to step up and actually create meaningful workflow processes.
The endgame for us is very similar to what we've heard others say. Definitely moving from electronic attachments to codify data is what we want to see. From the providers' perspective we have a very simple observation. The more codified data that I can give the payer, the better partner we are with them because they now can auto-adjudicate the claim.
But what's in it for us is that means they can turn the claim around quickly. For us quickly, the Holy Grail is real time. There's no way any payer can adjudicate a claim in real time if they're going to be having someone read it. We see the value of it definitely the more it becomes codified.
We also want to make sure that although the current approach to this is to have five main types of attachments, we don't think there should be a limit at least in the regulation. We think the limit should be limited on whatever the link codes can define and that the training partners want to use it for. But I wouldn't pigeonhole it into some artificial limitation. I don't see the benefit to it.
DR. SUAREZ: Thank you very much. We're going to go to Ruth-Ann and the VA.
Agenda Item: Veterans Administration, Ruth-Ann Phelps
MS. PHELPS: Thank you for the opportunity to make this presentation this afternoon. Before I make my remarks, I just want to say that I really appreciate Rob's presentation on unintended consequences. Our remarks address the questions posed by NCVHS and claim attachments and are organized into two sections. First, VA Healthcare's current use of claim attachments and secondly, our future perspective on claim attachments.
Current use of claim attachments -- we send both unsolicited and solicited claim attachments to third-party payers in Medicare. To first address unsolicited attachment, medical records are the most common attachment type submitted for procedures with specific modifier codes. The modifier codes for which VA submits unsolicited claim attachment include the following: incomplete procedures, discontinued procedures, increased procedural services, and procedures performed by more than one surgeon.
Claims with these modifiers are identified by a claim scrubber, which alerts the billing staff to retrieve and print the necessary documentation from VistA, which is our VA's integrated health record. The printed attachments are submitted along with the claim by the billing staff by fax to the Medicare intermediary or by mail to most payers.
Certain payers require referral and authorization documentation to be submitted with the claim. These claims are identified manually by billing staff who after submitting the claim electronically alert the utilization management department. The UM staff retrieve the necessary documentation from the electronic health record and submit the attachments by mail to payers.
Currently the VA also submits remittance advices as unsolicited claim attachments to support coordination of benefits. For example, a high number of Medicare Remittance Advices are submitted as attachments for secondary claims. Only about 10 percent of VA's payers accept electronic MRAs to adjudicate secondary claims. Over half of the enrollees in the VA healthcare system are also enrolled in Medicare. Consequently, this is a significant and substantial impact.
As for solicited claim attachments, medical records are the most common type of attachment requested. VA receives notification of attachment requests predominantly through claim denials on the remittance advice. For a one-year period ending in June 2011 the percentage of all denied claims VA-wide attributable to general data requests was about 14 percent totaling 380,000 claims.
Data request denials include solicitations for medical records and coordination of benefits attachments. Many of these denied claims had a generic remark code of “this claim has been denied without reviewing the medical record because the requested records were not received or were not received timely.” Resolution of these denials requires a phone call to the payer and extensive follow-up.
VA Healthcare's future perspective on claim attachments. We see great value in the future automation of claim attachments. However, we urge that any attachment standard and associated Operating rules not be overly complicated. As a rather large integrated healthcare provider, VA healthcare is complex itself. We do business with about 1,600 payers nationwide submitting over 10 million claims a year. As an overarching them we support simplification through all efforts to reduce the number of claim attachments and eliminate the potential for payer specific requirements.
VA suggests that a limited number of standard submission operating rules for unsolicited attachments be established. These rules should define specific submission scenarios that determine when attachments are required for all payers. For instance, an operative report is required for a modifier signifying a complicated procedure. These submission rules would be most effective if any additional unsolicited claim attachment outside of the defined scenarios were prohibited.
The establishment of such submission Operating rules stands to benefit both providers and payers, of which VA is both. For providers who do business with many payers, such as VA, standard submission rules would eliminate a burdensome amount of third-party agreements defining unsolicited attachment rules by payer. Standard submission rules would also allow for VA and other providers to build their systems to pull the defined claim attachments automatically from the electronic health record, resulting in greater efficiency and accuracy.
Limiting the scenarios when unsolicited claim attachments are submitted by providers would also lessen the burden on payers who must process and manage these attachments. Extraneous attachments could have various negative impacts on many parties, including extended claims adjudication times and the unnecessary release of protected health information.
Furthermore, for each Operating rule VA suggests drilling down to the actual purpose of the attachment request and to consider using or adding data elements in the 837 to fulfill the purpose whenever possible.
On solicited claim attachments payer requests should state the reason for the request and specifically note the document or data requested. VA encourages limiting what claim attachments payers can solicit in common business scenarios. VA encourages limiting what claim attachments payers can solicit in common business scenarios. The minimum amount of patient information necessary for claim adjudication should be requested by payer.
VA supports both structured and unstructured attachments. At this point many documents in the VA integrated electronic health record could not be sent as codified data in a structured template as they are scanned images.
Overall, in VA's view the claim attachments standard and associated Operating rules should be simple and consistent across all payers. This will reduce the current administrative burden of claim attachments on both payers and providers, ultimately improving the efficiency of the healthcare system. I hope these remarks have been helpful, and I think you for the opportunity to make these comments.
DR. SUAREZ: Thank you very much. We're going to go next to the payer perspective. We're going to start with Gail.
Agenda Item: Payer Perspective, Gail Kocher
MS. KOCHER: My name is Gail Kocher. I'm the director of the Industry Standards and eHealth Department within the national programs at the Blue Cross Blue Shield Association. The Blue Cross Blue Shield Association is a national federation of 39 independent community-based and locally operated Blue Cross and Blue Shield companies that collectively provide healthcare for more than 99 million, or one-in three, Americans. On behalf of the association and our member plans I do want to thank you for the opportunity to present here this afternoon.
I'll get right to the questions that you posed to us to present for you this afternoon. With respect to the most common business situations that require attachments today, what we hear from our plans is that it's primarily prior authorization and claims adjudication supporting information, which I think we've heard from other testifiers this afternoon.
You asked us for top-10 situations. Our plans actually narrowed it down to four. They mostly need both claims or prior auth related to medical necessity. For example, is it cosmetic, what it medical policy, by procedure code, those kinds of questions. It's a Not Otherwise Classified code that was reported. There are unusual circumstances identified, which is usually identified through the Modifier 22. And what the medical criteria was under specific member benefits.
In terms of requesting the documents from providers, primarily they're doing it by letter today. There is some electronic mail and some facsimile going on, but my plans are still primarily doing the hard copy that Rob and Robert talked about earlier.
How do we get the data back from the providers? We're getting mail, courier, hard copy reports, x-ray and diagnostic images. We do get some things through facsimile. We get some reports and other picture images. Then there is some limited use of the 275 X12N transaction for reports and images as JPEGs.
What type of attachments could be done through unsolicited? Our plans support unsolicited only when we have specific trading partner agreements involved because we think that situations need to be clearly identified. What are the specific reasons that providers need to take the time up front to get that data into us? Things happen all the time. I think Rob had a figure somewhere in the high 40s percent.
What are the situations that providers can work it into their workflow on the front end? Because we're very concerned about providers having to transfer large volumes of PHI and PII, as well as our plans having to then capture those large volumes of PHI and PII.
We also have concerns about if this happens outside of a trading partner agreement, it creates additional burdens for both payers and providers in respect to those large volumes of data. You have to receive it, store it, protect it. Providers also bear the burden then of documenting the minimum necessary if they send unsolicited. We do believe that trading partner agreements play a significant role in any unsolicited attachment.
What are the needs and requirements around provider signature and authorization? Today plans don't need in most instances provider signatures and authentication separately because they're relying on their trading partner agreement and provider contracts that have already addressed that up front. The verification process and the procedures that establish that electronic exchange handle that.
We have concerns, however, that this process will not work in the future if we start doing electronic exchange of data through other parties outside the current trading partner agreement environment, such as in a health information exchange. Moving into that environment, we will need to incorporate the use of electronic or digitized signatures or some other method to accurately authenticate both the senders and the receivers of the protected health information.
We've already heard a lot today about structured and non-structured data. We do see that there is a role, and down the road we could potentially get to a point where there is greater auto-adjudication and processing of attachments.
We do believe, however, that it's very important to start with the unstructured data exchange because it does provide some immediate value and efficiencies. It gets the data there quicker without adding the additional burden on all the trading partners that are involved in the data exchange of going to the high end. Having to deal with the structured data today, as we know, many of the electronic health records systems are not fully in a structured data format.
What are the other specific needs and requirements that are relevant to the development? We do believe that the data in the existing standards should be considered prior to determining the need to mandate attachments. We do think there is a role that ICD-10 may provide data that today is not available in using the ICD-9 code system.
There are new versions of the administrative standards that we believe need to be reviewed to ensure that any additional data gained through their moving to them, that we do not also then ask for it in an attachment. We believe that it's possible to modify the existing standards to avoid a need, and we want to leverage the SDO work that's already been done to review the potentially overlapping data prior to moving to any mandate.
We do believe that the human versus computer information is closely tied to structured versus unstructured. We think human-readable received electronically affords some value by reducing receipt time, and that we should move towards computer-readable to create additional efficiencies in processing.
We do support the use of full documents. This is what the providers are doing today. It limits them having to extract specific or individual pieces of data. We do think there needs to be greater standardization around data requirements and does support data being viewed all in a full context.
In terms of Operating rules, we think there's guidance for timing of submissions. How soon after request for a receipt should the provider send the information? How soon after a claim is received should the request go to the provider? We do think there are unique timing rules around unsolicited due to if an inbound claim is rejected, but you send the unsolicited attachment, that does create some additional challenges. And we believe we need to prioritize the base standard identification followed by stakeholder collaboration to identify the situations that will lead to the administrative efficiencies.
We think that multiple sources of data are acceptable. Standard formats and vocabularies have to be used. The key is the ability to understand the data that's being exchanged. Standards and Operating rules need to be the same across all data sources.
Finally, we do support moving to greater electronic exchange in healthcare, but we do see three things that have to happen to get that positive return on investment. The process has to manageable. We strongly support starting simply with the unstructured human-readable, get the pipeline established for the exchange, and then move to more robust data at a later time.
We would ask that HHS factor in the other mandates and initiatives on the IT agenda that, like claims attachments, do necessitate systems changes. And we believe there needs to be full stakeholder participation across all transactions. All of our member plans are committed to doing their part to work with providers and federal, state and local industry groups to try to improve the return on investment for HIPAA.
DR. SUAREZ: Thank you, Gail. We're going to hear first from EsMD.
Agenda Item: Medicare EsMD Project, Melanie Combs-Dyer and Craig Miller
MS. COMBS-DYER: I'd like to thank the committee very much for the opportunity to testify about electronic submission of medical documentation today. I'm the deputy director of the Provider Compliance Group in the Office of Financial Management at CMS. I've been there for over 22 years.
My current responsibilities include overseeing the comprehensive error rate testing program, or CERT program; the Medicare Recovery Auditor Program, sometimes people call that a RAC program; the medical review efforts of the Medicare administrative contractors called MACs; and the new electronic submission of medical documents, or EsMD Program
Medicare and Medicaid issue billions of dollars in improper payments every year, but most of those improper payments cannot be detected just by looking at the claim. It takes a human being, usually a coding expert or a clinician, to compare a claim to the medical documentation written in the patient's medical record at the time of service.
We at CMS hire review contractors to help find those improper payments. We call these review contractors MACs, recovery auditors and CERT contractors. Collectively these contractors send over two million requests for medical documentation each year to providers across America.
Providers respond to those requests by mailing or faxing the paper medical record to the requesting review contractor. But effective just two months ago, providers had a new mechanism to respond to these documentation request letters. We call the new system electronic submission of medical documentation, or EsMD.
Let me show you this to explain what today's paper medical documentation process looks like. The review contractor sends a documentation request letter in paper form through the US Postal Service to the provider who submitted the claim in question. The provider finds the medical record, makes a copy, boxes it up and sends it to the review contractor who requested it.
Let me briefly explain the submission pathways that providers currently have or will have in the future to submit electronic documentation to review contractors. First, there's the traditional Medicare connectivity that allows providers to submit claims. But it does not currently allow review contractors to electronically request documentation, nor does it allow providers to submit requested or unsolicited documentation to the review contractor, although that functionality is being planned for 2016. You'll hear Chris Stahlecker later talking about that traditional Medicare connectivity.
Second, one of our MACs has created a secure web portal that allows providers to submit requested and unsolicited documentation to the MAC. However, this is only in place at one of our MACs, our claims processing contractors. And even though there are a number of MACs who are also exploring this possibility, building a secure web portal is a fairly expensive proposition and we're not sure how long it will take for all of the MACs to be able to offer this service to providers.
The third form of electronic connectivity is the new kid on the block, EsMD. Today EsMD allows providers to electronically submit requested documentation. In 2012 EsMD will allow providers to electronically submit unsolicited documentation to review contractors. In 2013 EsMD will allow review contractors to electronically request documentation from providers.
You heard Doug talking earlier about the Nationwide Health Information Network, or NHIN, and how it's a set of standards and protocols and legal agreements that allow the secure and private exchange of health information over the Internet. It's similar to the types of standards and legal agreements that the banking industry adopted years ago that allow me to move my money from my checking account to my savings account, or this time of year move money from my checking account to Amazon.com or wherever it is I'm going to do my Christmas shopping this year.
It's because of those legal agreements and protocols and standards that the banking industry put in place years ago that I feel safe and secure to do all that electronically over the Internet. The NHIN is going to allow us to do that in the health IT world.
The NHIN is overseen by the Office off the National Coordinator for Health IT, and it includes standards for a secure gateway. A secure gateway is part of the NHIN Exchange that Doug was talking about earlier, and gateways allow large organizations to securely exchange health information with other organizations that have a gateway.
EsMD transactions are safe and secure because the EsMD system uses the NHIN standards. EsMD transactions may be less expensive to a provider compared to the traditional Medicare connectivity because the EsMD system is using the public Internet, while the traditional Medicare connectivity relies on private networks, which can be costly.
Here's what started in September of this year. This is what we call EsMD Phase One. This depicts how Medicare review contractors are still sending paper documentation request letters to providers. But now providers who choose to use EsMD can send the requested documentation to a health information handler that has an EsMD gateway.
An HIH is a company that handles health information on behalf of a provider much like a claims clearinghouse handles claims on behalf of providers. CMS has currently certified five health information handlers, or HIHs, to offer EsMD gateway services to providers, and we expect to certify several dozen more by January.
Once the health information handler gets the documents from the provider, they send the documentation packaged up using NHIN standards through their gateway to the CMS gateway. Once CMS receives the package, we unwrap it, take off all the security wrappers, remove the PDF files and send them to the requesting review contractor.
It's important to note that EsMD Phase One is not mandatory for providers. Those providers who like responding to documentation requests by sending paper or fax can continue to do so. But providers who want more information about using EsMD can find more information at our website, www.cms.gov/esmd.
Phase Two of EsMD is slated to being in January of 2013, and it looks very much like Phase One except that providers who sign up for EsMD Phase Two will no longer see the US Postal Service delivering those documentation request letters. Instead, the review contractors will send the request electronically to the provider's chosen HIH. EsMD Phase Two will not be mandatory for providers.
This is a busy slide. I'm going to go through it quickly. This says that we're starting today in 2011 by accepting from providers responses to documentation requests in PDF/XDR format. Next year we're going to try to accept responses to documentation requests in PDF/X12 format. In 2013 we want to move into structured orders and structured progress notes. In 2014 we hope to be able to have review contractors sending out structured documentation requests, as well as review results, letters, demand letters and others.
It's important to point out that EsMD payloads are not developed by CMS, but rather by the NHIN specification factory, or Spec Factory as we like to call it, which is headed by Craig Miller, who's testifying right after me. One key question that we have is are there enough staff on the NHIN Spec Factory to create all those payloads that the EsMD team wants to see?
The committee asked about Medicare requirements for signatures in medical documentation. Sometimes Medicare policy only covers an item or service when there's a valid physician's signature in the medical documentation. We at CMS have issued extensive instructions to our review contractors regarding pen and ink signatures. But for printouts or PDFs from electronic health records our signature instructions defer to review contractor discretion. For signatures in structured output from EHRs the CMS instructions are silent altogether.
CMS has recently partnered with ONC to launch the EsMD Initiative, where CMS is proposing that healthcare professionals use author-level, cryptographic, verifiable signatures. CMS is now seeking public input on this idea. Providers will likely not begin submitting medical documentation in structured form until CMS defines acceptable signatures for the Medicare coverage purposes.
The committee also asked about our perspective on structured versus non-structured documentation. We believe that non-structured electronic documentation is better than paper, and we believe that structured electronic documentation is better than non-structured electronic documentation, but only if two things happen.
First, the structured documentation must contain author-level, cryptographic, verifiable signatures. Second, the structured documentation must contain every data element from the medical record entry that the provider chooses to send. A summary isn't good enough. If the provider wants to be able to send the full note, he/she needs to be able to send the full note or the full order or the full discharge summary.
What about requesting a specific data element rather than the full document? For many improper payment reviews the review contractor needs to be able to see the full document. For example, the Office of Inspector General has found that some labs attempt to game the system by inappropriately bundling or unbundling the services on a claim form. It's only by seeing the full document from the medical record that the review contractor can determine if an improper payment exists.
Thank you for inviting me today. We really believe that EsMD is an exciting program, and I hope that the committee will endorse EsMD and encourage providers to use it. But please keep in mind that for EsMD to expand to its full potential, many more payloads will have to be adopted by the EsMD NHIN Spec Factory. I welcome input and recommendations from the committee.
MR. MILLER: My role with respect to EsMD is, as Melanie said, I have chaired the Specifications Development Workgroup. I'd like to provide you today with some context and perspective on some of the technical aspects of what we're attempting to do with EsMD and some of the implications of it that might not be immediately obvious based on the discussion today that might be helpful to inform the discussions and recommendations of NCVHS.
I'll start by articulating some of the architectural principles that we thought were most important when we began this journey with Melanie close to two years ago with respect to specifications development for EsMD. The first one we articulated was that we wanted to be minimally inventive.
Wherever possible we wanted to build on existing capabilities that exist within providers and payers. We wanted to use existing standards that had been adopted by the payer community. We thought it would be important to leverage national standards for data and vocabulary wherever they may exist. Finally, as one of the original authors of key components of the NHIN Exchange platform, including its messaging standards, I thought it was important to align with NHIN Exchange wherever possible since, as Dr. Fridsma articulated earlier today, we see that as really the future of large-scale health information exchange.
The second principle was we wanted to be open. One of the things we've done with EsMD from its inception is to invite the key standards development organizations who have a role to play in this to participate in the development of the standards. That's included the ASC X12 people, HL7, Council for Affordable Quality Healthcare and the Office of the National Coordinator.
Beyond that, one of our objectives was not trying to develop specifications that would be only of utility to CMS. One of our objectives from the get-go has been to try to develop specifications that other payers could utilize equally well. One of the things we're doing as part of the ONC S&I Initiative is to invite the large payer community to participate in the effort to build standards for EsMD, which we will.
The final architectural principle that was important was to be forward-looking. As Melanie has articulated, although we're beginning the process of focusing on claim submission, there are many other aspects of the administrative transaction lifecycle that will be amenable to standardization similar ways. We would like to ensure that whatever we develop for EsMD is of value to the larger process and not just to this one step within the claims lifecycle.
One of the things we want to talk about here is the fact that when we think about standardization, we really think about it in three layers. To be successful, we feel that we need standards for the transport of the information to ensure they can be transmitted and received in a secure, interoperable fashion over the public Internet.
We need standards for packaging, how that data is organized into structured, interoperable representation, whether it be HL7 CDA templates or something else. Finally, there's a need for standards around vocabulary for terms such as diagnoses, procedures, test results, and other components of a medical encounter.
Why is transport important? EsMD is working to standardize transport specifications for the purpose of submission of medical documentation for several reasons. First of all, CMS wants to give health organizations an option if they choose to move away from more expensive proprietary networks to less expensive non-proprietary networks, such as the public Internet for information exchange. I would emphasize that as an option for providers, not a requirement.
Second, from the perspective of the Office of National Coordinator, as you heard Dr. Fridsma testify earlier today, there's a strong belief that providers and other health system participants should not be required to implement one stack for clinical transactions and another for administrative transactions. I'll have more to say about that at the end of our discussion here today.
Finally, working with standards organizations such as CAQH, we've observed that transport is an important component of the interoperability specifications that are necessary for the payer community. All that said, we recognize that NCVHS may or may not elect to focus on transport standardization. But in any event, we view collaboration between CMS, NCVHS and the various standards development organizations on this issue as a desirable outcome.
Let me give you a brief synopsis of our current progress. If it will be helpful to the committee, we would be more than happy to provide links or copies of the current standards development work if that would help to inform your discussions going forward. We have already completed our first version of the submission of unstructured medical documentation using NHIN Exchange specification known as document submission, which uses an underlying technology called XDR. That has been validated and is being implemented in an initial production phase today.
We are nearly complete with an equivalent specification for submitting unstructured medical documentation using a different transport, using X12 and the CAQH Core Phase Two Connectivity Rule. You may well ask why we are tackling the same problem in two different ways.
The answer to that is that the NHIN specifications for submitting documentation are already available and are widely used today within the NHIN Exchange community. We wanted to make sure that we took advantage of that and, indeed, the initial pilot implementation EsMD uses those specifications.
However, we also wanted to be able to meet payers and providers on their doorstep using the standards that are already widely adopted within the payer community that have been promulgated by CAQH, such as the Core Phase Two Connectivity Rule and the existing X12 specifications for EDI. Therefore, we are electing to provide two alternate mechanisms for providers and payers to participate in the process using these standards.
Longer-term, however, we would strongly desire to see harmonization of transport between the NHIN Exchange and the CAQH Connectivity Rule. The good news is there are only a few relatively minor issues to address there in terms of some elements of the way meta-data is articulated and some other things. We are working with CAQH to see if we can accomplish that.
Melanie has already talked about the desire to adopt NCVHS recommendations for medical documentation and implement additional transactions, so I don't think I need to discuss those issues further.
Others have already discussed the issue of structured versus unstructured data from various perspectives. Let me provide a brief perspective on some issues that may not have been discussed already. From our perspective unstructured documentation for EsMD typically looks like a PDF file that often contains scanned images of the paper medical chart. This has many advantages. It's less complex and less expensive for providers to adopt, and it provides a wet signature in digitized form as part of the scanned image of the chart, which neatly addresses the authentication problem.
However, there are disadvantages. It cannot support automated review. There can be readability and consistency issues if you're looking at paper charts of handwritten content. And potentially you're looking at large file sizes. That said, this does reduce the time and expense associated with the handling and mailing of documents.
Structured content, by contrast, tends to focus on representations such as XML, containing some or all elements of the medical char. This enables automated review by payers and providers of claims attachments through business rules engines. In fact, some of this is already occurring in other similar domains.
The Social Security Administration is using precisely this approach using the implementation of business rules engine to automate and assist the process of adjudication of long-term disability claims using this kind of structured documentation. Furthermore, this requires less handling and less effort by the providers over the longer-term.
That said, there are disadvantages, standards are still being developed. It requires EHR support to emit clinical data in the structured format. And as we'll see later, authentication issues must be addressed. That said, the benefits are substantial as well. the potential efficiency gains go beyond savings in terms of paper and handling to reducing the time and expense to adjudicate claims. And longer-term, this rich set of clinical data being submitted to support claims can be used to create repositories of data for analytics purposes to identify and reduce fraud and serve other purposes to create learning and so improving healthcare systems.
Authentication is a desirable outcome for using structured documentation, but there are technical issues that need to be addressed. Specific issues that need to be addressed are the fact that you must structure the document, such as the HL7 CDA document, in such a way that individual segments of the document can be signed because one document may represent clinical content that has been originated from multiple participants within the healthcare system. Each of those elements must be uniquely signed so that CMS has confidence that the information does, in fact, originate from the provider who's asserted it.
Secondly, beyond the issue of the document itself, we need to look at from a practical perspective how you can distribute digital certificates to individual providers, and furthermore establish certificate authorities that can be trusted by the payers as a basis of authentication. All that said, you need to make that process as painless as possible for providers, which typically means implementing this authentication mechanism somehow through an electronic health records system.
Another technical issue that's worth a moment's discussion is the bidirectional exchange of information. As Melanie indicated, by 2013 CMS desires the ability to send the request for electronic information, what people in XPX12 world call the 277, electronically and not by paper. This is certainly desirable, but there are some downstream impacts of that that need to be considered.
This requires CMS or any other payer using this mechanism to be able to register providers as requesting and being able to receive those requests for medical documentation electronically. Second, it requires the mechanism for enabling CMS to locate those providers, which in turn infers some kind of requirement for a provider directory service. When we think of that, let's think about the downstream impacts of that, not simply the fact that the information exchange itself must be standardized.
Let me close with a few final thoughts. We are committed to the adoption of national standards, and we absolutely love them and are encouraged by NCVHS's role in helping to recommend standards in this domain. I want to expand further on something that Dr. Fridsma said earlier. We see that creating specifications for all levels of claims attachment will open the door for new innovations and improvements to the health system through the widespread exchange of structured clinical data.
Like Dr. Fridsma and many of you, I'm old enough to remember the time when there was no single common web. There was AOL and there was CompuServe and other separate wall-guarded services. Each were proprietary with their stacks, their software, their transport and their content.
We see an enormous opportunity to have a common platform for this purpose that provides all kinds of new innovations that we can't even imagine today. When the Internet and the worldwide web were invented, I'm sure no one was thinking about the fact that down the road there would be eHarmony, Google Earth and NHIN. But here we are because there's a common platform that everybody can build on.
I'll leave you with a couple final thoughts. Structured electronic claims attachments have the potential to dramatically improve pre-payment fraud detection when they're combined with other technologies CMS is already adopting, such as predictive modeling. Finally, on behalf of ONC I'd like to say that extending NHIN to encompass administrative transactions will be a significant driver of overall network growth.
There is certainly great benefit to providers to being able to do clinical exchanges with other providers, but if you really want to get a provider's attention, tell them you found a way to expedite claims reimbursement. We see this as being an enormous opportunity in that domain. Thank you.
Agenda Item: Medicare Perspective, Chris Stahlecker
MS. STAHLECKER: I thank the members of the subcommittee for actually holding these hearings. I'm very pleased to be here to speak for Medicare fee-for-service experience with claims attachment. There is no question that Medicare fee-for-service, the program itself would benefit from an electronic standard for attachment.
We've looked at the annual volume of claims for Medicare from 2010. We're well over a billion claims. If we use any of the other metrics we heard this morning -- from Wes's presentation I think it was estimated 5-20 percent, from Rob's estimate anecdotally 40 percent -- any small percentage of over a billion claims is a large number to be processing on paper with a manual review process. The Medicare program would definitely benefit from an electronic transaction.
In response to the questions asked, the most frequent areas requiring attachments are two categories, pre-payment and post-payment for medical review purposes or provider review purposes, also in the recovery and audit or appeals area.
Medicare currently sends additional documentation requests, building on Melanie's presentation. An ADR is a solicited attachment sent via a mailed letter. The return part of that process is when the provider sends in the response to that request, and these responses are received as mailed media for the most part, some fax, and we do have one pilot that you'll be hearing about later.
In the solicited and unsolicited categories and the Medicare model, an edit will stop a claim from completing its adjudication process to generate that automated development request letter, additional document request. And providers would send in the solicited attachment type, but an examiner would use that information to complete the adjudication. In an unsolicited model the provider would be versed in the billing requirements of the payer in Medicare fee-for-service and would send that attachment information in with the original claim. We do have one pilot underway.
Benefits of electronic claims. If we could eliminate that print/mail operation for the generation of these ADRs from the payer perspective, we would greatly save some financial outgo and the timeliness would also be greatly improved by removing this mailroom operation from both the payer and the provider's workflow. Of course, building on Craig's point, if we can enhance the receipt of dollars back for the provider, we would improve adoption.
We did have some estimated cost data, and we looked at Medicare processing of complex claims. There is a requirement that we have in play right now that a complex review is conducted on a million claims annually. That one million is not one million per MAC; it's one million for all MACs because a complex review is very detailed.
We've estimated the cost to send out that ADR. It's 71 cents. So just for the complex review -- and not that footnote that it does exclude the RAC, the CERT and the ZPICs that Melanie had spoken about. This is just a complex medical review. It was nearly $1 million just to send out the documentation request letter.
When that information is received at the MAC and then prepared for the medical review process -- and again, that's a manual review -- that cost is approximately $33 million. We've estimated the cost at 50 cents per page for mailroom handling and scanning, and we've estimated the number of pages for this costing estimate at 65 pages. But in some cases we receive well over that number.
In summary, we would say Medicare program on an annual basis could clearly cost avoid in the neighborhood of $33 million just from this complex medical review if we had an electronic attachment standard that we could implement. Dramatically Medicare alone as one payer and one simple focus would have a great opportunity to avoid costs.
We are planning on improving the current workflow for processing these paper attachments that are received. Why are we doing that? We believe now would be a great opportunity to improve our infrastructure for handling this in anticipation that we will have a standard electronic attachment.
This plan work is that we will require contractors to accept faxed or mailed unsolicited attachments only for the claims that have been submitted electronically. We'll make use of this new segment in the claim, the paperwork segment, and when that is populated on the electronic claim, this new process will be invoked.
We're also exploring this workflow to be conducted via EsMD. This will include a specification for a cover sheet that providers will use to submit still the paper attachments. The attachments will be imaged and stored in the claims adjudication process. Only the attachments that are affiliated with this electronic claim will be considered. Examiners will not review unsolicited attachments that might be received simply because it was submitted.
We're revising our workflow. We're dovetailing it to a potential electronic standard being available. We plan on implementing this new process on or after or April quarterly release. It may need to slide a quarter, but it should be in 2012. This process does not affect our paper claim handling at all, and any attachments coming in our paper claims will be processed as they are currently.
In summary, Medicare fee-for-service fully supports the EsMD model workflow from health information handlers to the gateway, but we can't emphasize enough hat we need a standard that's going to travel over the existing pathways that are already established from providers or their vendors and clearinghouses to the Medicare administrative contractors, the MACs.
I can't emphasize enough again the points made earlier that a simple standard based on images, perhaps limited text, could achieve some early economies and also let us learn how to process these attachments and pave the way for the coded attachments in taking us toward an automated adjudication.
Finally, CMS would like to make some observations that may potentially be action items for NCVHS. We would strongly suggest that the Operating rule, the authoring entity be named now so that as we proceed and finally develop a claims attachment standard, that we can go through that exercise together with the Operating rule entity and the SDOs so that it's not a sequential activity, it's a concurrent activity. We feel that the NCVHS could recommend that Operating rule authoring entity be named now for claim attachments so that additional development step could take place.
We would also recommend that NCVHS could request X12 to simplify the 837 claim transaction. There are still some data inconsistencies anecdotally between the 837 institutional claim and professional claim or ambulance attachments. Some certain key data can be contained in a professional claim but not in an institutional claim. We think it could benefit from a look to simplify that claim and make the attachment more standardized use of the data content.
Finally, this is really an observation and also a request for NCVHS consideration. There's considerable interdependency between the standards development organizations, including now the Operating rules, Health Level 7, X12 and whoever will be the Operating rule entity for attachments. Each of these are based on volunteer efforts to not only develop, but also sustain the standards. That is a key concern. We're looking at future standards here, and we're already experiencing a shortage of skilled volunteers to complete the work for the attachment standards, as well as prepare for HIPAA-next.
The final takeaway that we would ask ourselves is how we come to a point where the industry is moving faster than the current SDO structures based upon volunteer efforts can accommodate? We need to have a hard look at that and see if there aren't some steps we should be taking now to align our forces. I thank the committee for permitting me to comment.
Agenda Item: Clearinghouse Perspective, Debbie Meisner
MS. MEISNER: I'd like to thank the members of the committee for inviting me to testify on behalf of Emdeon as a clearinghouse. I'm sure by now you're all aware of Emdeon and our structure, so I'll move right into the testimony.
As a clearinghouse that handles very large volumes of claims and other transactions each year, we understand the challenges and the opportunities associated with automating claims attachments. The processes required for providers to respond to the requests for additional information, the solicited attachments, or to send information proactively in the unsolicited attachments can be cumbersome and time-intensive. Standardizing the manner and the circumstances under which attachments are transmitted will reduce the ambiguities and bring greater accuracy and efficiency to the workflow.
We have a consistent trend towards carving out certain claim types for the transmission of paper, and we've continued to work with the payers and the providers to understand the reasons for this cargo. One of the most significant reasons is the requirement for supplemental information to support the adjudication of claims. For this reason Emdeon has decided to make a significant investment in automating the medical claims attachments.
Two years ago we launched a pilot program with two large health plans and recently we completely a detailed analysis of our experience. We performed the detailed time and motion studies comparing current state processing of medical claim attachments compared to an automated electronic attachment solution.
We estimated that the return on investment for the automated solution approaches four-to-one, and the cost savings associated with the solution could reduce a health plan's cost of requesting and processing paper attachments by nearly 50 percent. For example, Emdeon conservatively estimates that one of the payers studies spends at least $2 million annually processing paper claim attachments, so a 50 percent savings of this would amount to over $1 million.
Beyond the financial benefits, implementation of automated solutions can have additional benefits such as improved provider relations and improved administrative efficiencies driven by factors such as fewer lost attachments and a shortened claim payment cycle.
While early phases of the pilot project are focused on attachments directly associated with medical claim processing, the capabilities of the solution can also be leveraged to reduce the volume of paper associated with the provider dispute resolution processes and prior authorization processes. These workflows are conducted at health plans and represent the bulk of the attachments processed outside of the core claim administration.
Emdeon has also introduced processing of claims for Workers' Compensation and property and casualty, as well as auto accident carriers. We have seen significant adoption from the carriers, but have seen more limited volumes of transactions from the provider community. We're working to address these challenges through outreach and education.
Generally, providers have been trained to carve out these types of claims from their normal electronic submissions. Introduction of the electronic submission for these new types of claims will require some retraining and adjustment of the work process, but we believe this barrier can be overcome in time as providers have the opportunity to see the benefits of the electronic submissions of these claims.
Overall, in our experience, claims attachments can be implemented effectively and in a manner that achieves cost savings. The key to successful implementation will be taking an approach that builds on the mechanisms that are working today. Towards that end, I would like to now move into the specific questions under consideration by the subcommittee. What is the current status of the standards? Emdeon would defer to the standards development organizations to provide you with that input.
The future outlook for standards and harmonization -- where do we see the standards for attachments going? As we look ahead to how attachments might be used in the future, Emdeon believes there will be a long-term need for additional information in the form of claims attachments. We also believe that the information can be used to facilitate other processes such as referrals and authorizations, much like our approach to our pilot program, which includes plans to expand the use of attachments to other processes in later phases.
Emdeon acknowledges the importance of harmonizing standards for claim attachments with other standards that impact the exchange of clinical information. We will continue to work with each of the SDOs including X12, NCPDP and HL7 and the joint workgroups that have been established to address this need.
We would like to emphasize, however, the importance of maintaining the use of the ASC X12 275 transaction as the mechanism for delivering the information. There appears to be consensus that the X12 wrapper can and should be used for all exchanges between providers and health plans, and the industry is generally prepared for this kind of approach. Thus, Emdeon strongly recommends that the ASC X12 275 be the mechanism for transmitting the information for all exchanges between providers and health plans and that the X12 wrapper be included in the HIPAA adoption of the claim attachments.
As to question three, are all the priority areas identified by providers and payers, Emdeon encourages the standards organizations to continue their efforts to get stakeholder input on the components for the claim attachment standards to ensure that their needs are met and to avoid unintended disruptions or duplications of effort. It will be critical to identify the use cases for how information is used today and how it is expected to be used in the future, particularly in the context of the new delivery models like the accountable care organizations, bundled payments for episodes of care and other reforms.
On the question of Operating rules Emdeon encourages both the standards organizations and the potential Operating rule authoring entities to collaborate from the outset and seek extensive input from the industry. In addition, the industry would benefit greatly if NCVHS could help to define a path for the process and clearly delineate roles and responsibilities to avoid some of the overlap and duplication that we have seen in previous efforts.
In regards to the content of the Operating rules, Emdeon recommends that Operating rules focus first on defining the circumstances under which unsolicited claims attachments would be used. Specifically, Emdeon would recommend rules to call out the use of the unsolicited claims attachments whenever the procedure code modifiers 22 and 62 are used. Emdeon believes that any other rules for the use of attachments would best be handled in trading partner agreements rather than in the Operating rules.
We are very concerned about the possibility of having 50 different sets of state requirements, and we hope that the development of a reasonable and effective set of standards and Operating rules for claims attachments will help to eliminate the need for a patchwork of new state regulations.
As to the authoring entity, it is important to have collaboration and coordination among the standards organizations and potential Operating rule entities. Overlapping and duplicative work creates confusion and distraction in the marketplace. We urge all parties to work together on a solution for improving the process for developing and coordinating and maintenance of standards and Operating rules.
One important point that Emdeon would like to stress is that there is currently a lot of work being done within the Workers' Compensation and dental industries in using documentation management systems, and we would hate to see that get broken in the process. We encourage the committee to consider making sure that other methods other than EDI exchange of information be considered. I appreciate the opportunity to share this testimony with you and thank you again for your attention.
For members of the committee, I want to let you know we did receive written testimony from the American Dental Association related to claims attachments, so we do have written input from them.
Agenda Item: Claims Attachment Pilot, Laurie Darst and Laurie Burckhardt
MS. DARST: I'm Laurie Darst, revenue cycle regulatory advisor for Mayo Clinic. On behalf of myself and Laurie Burckhardt, the EDI manager of WPS Insurance, we want to thank you for the opportunity to testify today. During testimony we will do an overview of the Mayo Clinic WPS Claim Attachment Project and also share our respective comments and experiences.
In 2005 Mayo Clinic and WPS, which is Minnesota's Part B Medicare carrier, began discussions on the possibility of implementing claim attachments. The goal was to look for cost reduction and savings. Our intent was to go beyond the proof of concept. We wanted this to be a project, not a pilot. We wanted to be able to replicate this to other trading partners. This was intended to be a long-term solution for both WPS and Mayo. In addition, we wanted to also utilize the most current proposed solution, and in 2005 it was using the X12 275 transaction with the HL7 CDA Release 2.
After reviewing numerous requests for information, we uncovered a high volume, high dollar request. This situation is with operative reports -- and I think that Ruth-Ann had mentioned this also -- when a surgical procedure was performed and complications developed or additional surgeons were required.
The coding staff at Mayo then modified the surgical CPT code with a 22 or 62 modifier to reflect additional costs that were associated with that procedure. Because WPS always needed to have the operative report to calculate the correct reimbursement, we discussed the possibility of using an unsolicited claim attachment. We felt from our perspective we could replicate this to every other payer.
Now I'm going to share specifically Mayo's perspective on this project. We worked with our internal IT staff to develop a flag for all of these scenarios where there was a 22 or 62 modifier. We pulled the operative reports from our SIRS system, that's our surgical system. It's a bolt-on system to our EHR system.
Our data was sent as text messages, not scanned images. We assigned a claim control number to the operative report and to the claim so that nurses at WPS could re-link back the claim and the operative report. Then we sent the claim and the attachment directly to WPS to not use a clearinghouse at all. This was a direct connect.
Our experience is that we significantly reduced staff time associated with eliminating the paper handling. I think earlier today we had heard about what are some of those different paper process staff time pieces. But what we discovered also was the payment for these services were received 20-30 days earlier than that paper process, and for providers that's a key issue, those days receivable.
We've been successfully transmitting electronic claim attachments to WPS over the past plus-five years. Our goal originally was to expand this to other unsolicited attachments with WPS, and then to take this out to other payers. Unfortunately, we had competing priorities, so we've just continued to do the surgical reports.
I just want to share some other general observations with you. Providers receive requests for additional information or notification that there is a need for additional information in two distinctly different ways. One is the claim is pended at the payer's office and they send a letter or request to the provider much like what we did with our pilot when WPS sends us that request for an operative report. The provider usually has 30-60 for before the claim would be denied. The second way we're notified that there is a need for additional information is a charge is denied on the 835 remit. The information is communicated to us using a CARC/RARC code.
Regardless of the mechanism, it is essential for payers to clearly indicate what is actually needed. A request for medical records is simply too vague, and many times they simply need to have a physician's note or a test result. As Ruth-Ann had indicated previously, in these situations where we get these vague requests we simply have to call the payer to find out what is it that you really need. This is an opportunity for Operating rules.
One other thing I want to share with you is a survey that we did at Mayo on the high-volume requests that were received either from a pended claim, either from we know that the payer needs this information, or from those denied charge amounts.
The operative report with the 22/62 modifier was one of the highest. That comes from our SIRS system. Miscellaneous or the NOC procedure code descriptions -- I think Gail talked about that in her testimony. This is another high-volume request. This actually does not come out of our EHR system; this comes out of our practice management system.
Invoice purchase price -- we get a number of these from payers, especially Medicare, where we are using a high-dollar solution with a procedure. They want to know what was the purchase price that Mayo paid or a provider paid. We need to send them that invoice. That invoice does not come out of our EHR system; that comes out of our purchasing system. The other items that we came across were radiology medical necessity documentation, lab results, which again is another bolt-on system for large academic medical centers, and clinical notes.
Just some other opportunities -- I think we've heard Workers' Compensation at least in the State of Minnesota does require medical records for all claims, so this is a great opportunity. We do have in Minnesota legislation that requires all claims to be sent electronically.
We currently have a best practice in place in Minnesota that we send the claim electronically and we fax a cover letter and the attachment and it's matched up at the payer's office. It's not the most efficient process for us to go through, and a standardized transaction would be much more efficient.
Finally, just a couple comments. Not all requests for additional information go to a provider's EHR system. Again, large hospitals, large providers have multiple bolt-on systems, so this is something that we want to consider when we talk about enveloping the claim attachments.
Mayo supports the use of that 275 transaction based on our experience. Finally, the most significant opportunity for cost reduction is the unsolicited attachment, but we agree that it does need to be by trading partner agreement or by Operating rules. Now I'm going to turn this over to Laurie Burckhardt to share her experience with the project
MS. BURCKHARDT: I'd like to extend my appreciation to speak today to the committee regarding claims attachments. As Laurie Darst has already said, we did the unsolicited. I really am going to push for that because the unsolicited was something at WPS that we did. It was an EDI initiative, and because it was an EDI initiative, unsolicited was the only way for it to work.
We identified from a high level what were the top claims that had to come in. When we looked at it, it required no processing system changes, whether we're talking our Medicare division, our TRICARE division, or even our commercial division.
We worked with our EDI IT staff to develop a method. We flagged a claim, any claim that comes in that has that claim identifier that Laurie talked about earlier. we had the attachment come in, and we used that linkage to tie the claim with the attachment. Then we send it directly on to our nursing staff for the medical review process. As Laurie's already stated, WPS and Mayo work together with CDR Release 2.
WPS nursing staff reporting claims attachment has been the most efficient process for them when reviewing claims. There has been no need to request additional information from Mayo for these unsolicited claims. They found that they never received more data than was actually needed for the claims processing, which I think are two very key points that when you have entities that work together, it is possible to work to do it. It's also important to note that our nursing staff has really been pushing me to push this off onto other providers. I'm going to talk about that in just a few minutes.
WPS has had ongoing discussions with providers who submit a large volume of claims for additional information needed for claims processing. Many of these providers have expressed a positive interest in unsolicited claims attachment with WPS, but needed to wait until either their new EHR system was implemented, they went to new billing systems.
And due to then to the 5010 implementation, unfortunately that has really pushed us back. What we have to remember is that 5010 we've known about for two years, so I've been hearing the same reasons for two years, and now I think I'm going to have to wait for ICD-10. We'll see what happens.
As already stated, there are basically two methods for asking for additional information. We're not talking anymore about unsolicited claims attachment, we're just talking about process today. We either send a letter faxed or actually our commercial and TRICARE division does use secured email. Then the service can be denied for missing information on the 835 transaction. Or unfortunately in our TRICARE and our commercial business we're only about less than 50 percent of doing electronic, so it is a paper explanation remit.
Some of the types of attachments that we receive -- and I think you've all heard the same story that they seem to be the same attachments. The request that we're going to be talking about came from all three lines of WPS's business: Medicare, commercial and TRICARE. The first five that you see, the miscellaneous procedure codes, medical necessity, invoices, ambulance and actually op reports -- I could even come up with top 10 because by the time I got to number seven and eight and nine, it was like less than 2 percent. The top five actually equate to almost about 69 percent of all attachments that are being requested for.
Under the miscellaneous procedure codes there's the thought with 5010 when you submit an NOC code, now you must also send the description, and unfortunately the description is I've got the flag. The medical necessity, the invoices, and ambulance, still continues to be a big one. We have op reports, lab reports and authorization requests.
Again, WPS supports the 275 transaction as a wrapper around claims attachment. The structure that 275 identifies is the sender, so who is submitting that to WPS. What is the file for and who is the receiver of the data? That allows us just as the claims makes us sure that we have our EDI agreements in place, we know who's sending it, what business it's for because even if it's Medicare, I have more than one contract for Medicare.
Providers already have connections established either directly or through clearinghouses to WPS for their electronic transactions. The use of the 275 ensures that the current methods of transport established can continue to be used with limited cost for health plans and providers. The use of the 275 transaction would allow the current use of EDI agreements in place to cover most of the provider signature requirements that may be necessary for attachments.
DR. SUAREZ: We're going to end with a presentation from Elizabeth and Donna from Medicaid.
Agenda Item: Medicaid Perspective, Elizabeth Reed and Donna Schmidt
MS. SCHMIDT: Thank you for the opportunity to testify. I am the deputy division director for the Division of State Systems in the Center for Medicaid and CHIP Services in CMS. I am here with my partner, Elizabeth Reed. She is our technical authority in this area.
We are here representing the state Medicaid agencies. Unfortunately, states were not able to attend. However, we were able to pull together a small group of states, about 25, to work together on the questions and to put together a survey on the appropriate information for today.
MS. REED: As for question number one, as Donna mentioned, we spoke to about 25 states. We received responses via the workgroup that we conducted, as well as some written responses that we received through email. I just want to note that there were a variety of perspectives, meaning some were more paper-focused where others are more electronic-focused.
As far as attachments for the first question, these are the variety of claim attachments that are currently being received from the states. When I say TPL on the first bullet, in the 837 there was information where it can be provided in the 2320 loop with the appropriate cast information stating how the other primary payer paid. But sometimes if the patient shows as having other insurance in their eligibility file, they still require to see that explanation of benefits on paper. Others are filing limit; manual pricing; the HAS claims, which are the hysterectomy, abortion and sterilizations; prior auths; etc.
The top 10 situations -- I've actually provided more because I wanted to include all of the states' perspectives. As far as the claims, it's on the first bullet, and these are the variety of claims that require the attachments. On the next slide you will see the variety of authorizations that require attachments.
For the third question, how are the requests currently handled, as you can see here, the attachment can be submitted electronically with the confirmation number, which is then matched to the claim. They also submit back the claim denials, and then the provider resubmits. Providers are also notified in advance as far as what claim types or what claim submissions require attachments. Then claim denials contain explanation of benefit codes, which indicate the denial was due to no attachment.
On the next slide there is some additional information about pharmacy claims. Currently the claims attachments are received via fax, email, or a letter. I think we can move onto the next slide.
What are the ways states are currently responding, submitting or receiving attachments? Attachments submitted electronically assigned a confirmation number, which is then matched to the claim with the same confirmation number. Some states are actually utilizing the PWK segment in the 837. They're also accepting attachments via paper claims submission and via an indicator on the electronic submissions. Then again, they're accepting them through fax and mail. Certain states actually have web portals where they can upload the attachments securely.
For question five, what types of attachments are or can be done as unsolicited, there's a lot of concern over PHI. Most of the attachments currently are viewed as unsolicited. I don't think anybody had particulars about solicited attachments on here.
For question six, what are the needs/requirements for a provider signature, there's a lot of debate about this. Electronic signature accepted provider checks box on enrollment. There are also federal requirements for the HAS claims, which are the consent forms, and the regulation is cited here. For DME and medical supplies they would like to see the official invoice, letterhead or catalog page. Some things that don't require attachments are TPL claims. The last bullet as far as some states accept stamped signatures, they're referring to the paper claims today.
For question seven, what are our perspectives on data structured data messages, you can see a variety of responses here. Most of them are in support of structured data messages versus non-structured.
For question eight, what are other specific needs/requirements on attachments that are relevant to the development of content standards, not all additional information needs to be sent as an attachment. Use all sender discretion data elements on the claim. Here are some examples of what they would expect to see, which are dates, beneficiary signature, dollar amounts. Some claims still need physician signatures. On the last bullet there are some required data elements that they would like to see in the structured format.
For question nine, what's their perspective on human versus computer types of attachments, they feel that it's definitely a provider benefit. At the present time we are only capable of human-readable attachments. There is no preference. Industry may not be ready for computer attachments is a concern of theirs. There would be less staff able to view PHI if the attachments were electronic.
For question ten, what are the perspectives/practices regarding requiring a specific data element, their responses are system has note capability. For example, provider could use THS lab results. They require the minimum necessary. As long as the full document is retained in the patient's record and the specified data element can be supported if the need arises, submissions of the specific data elements would be an acceptable practice. Their last response was most reviews require many data elements.
For question eleven, what are the areas where national standard business rules for requiring/submitting attachments would be most beneficial, their responses were federally mandated, ensure Medicaid is payer of last resort.
We think national standard business or operating rules can be applied to business requirements for attachments. For third-party liability a standard form/rule including CARC/RARC and group codes such as the contractual obligation or patient responsibility, other payer types. Then there was a response about timeliness. They would be concerned about how long they would need to keep some of the claims as suspense before releasing a denial. Then the receipt of medical records and lab.
For the final question, what are the perspectives on the source of data, they stated data needs to be available from all records systems, both the EHR and administrative, and any other perspective was the provider/facility is accountable for accurate submission of all claims and should retain data to support the submission.
In conclusion, a consideration that I'd like to provide from my speaking with the states is that not all states currently implement the 277 CA, so I think most of the responses as far receiving the document control number for the specific claim will come from the 835. That's all I have today. Thank you for your time.
Agenda Item: Questions by Subcommittee Members
DR. SUAREZ: I think we're going to go very quickly into questions from the committee. I want to invite members of the HIT Standards Committee to join us. I know Wes is one of our members. We welcome him to join us at the table here.
I was taking notes and pointing out what are some of the major themes that I heard, and I want to play them back. I heard first of all, there are a lot of claim attachments being done today. The vast majority are being done both the solicitation and response by mail and by fax. We heard very little being done electronically.
There is clearly strong support for moving towards electronic standards. There is some interest in not needing to wait until January of 2014 to get started. There's a consistent message about starting simple, perhaps with the human-readable approach, and then moving to more complex like the computer variant approach.
There's strong value seen in the unsolicited approach, but there are also some concerns about possible “abuse” of the requests for attachments. There's certainly recognized value in the Operating rules, but for certain specific areas, for example, providing guidance for timing, reasoning for submission, etc.
There is an attempt to really reduce rather than increase the number of attachments that are needed and limit the amount of attachments that are requested. There is some consistency across the board in terms of the priority areas. It seems clear that there is a need for attachments by most payers for things like authorization requests, medical necessity, the miscellaneous procedures, code 22, invoices and documentation, the ambulance, the operative report, the lab report. It seems like the priorities continue to be consistent. In most cases it sounded like Medicaid had quite a few other items as well.
There's general support for the use of the 275 wrapper, the X12 wrapper. In fact, it was pointed that it will allow the current EDI agreements to cover the provider signature requirements and the routing through the current EDI process and the clearinghouse processing using this wrapper.
It's important to name the Operating rule authoring entity now to begin to allow the industry to work towards a consistent and complete set of operating rules. Reduce and eliminate the variability across payers and states. That's ultimately the goal really, to try to reduce or eliminate that variability. Those were my top messages. I know I missed a number of them. I just wanted to play them back. We will probably want to go now to questions.
DR. WARREN: I have one really specific question and then open it up. Robert Barbour, you had mentioned that providers didn't always know about what should go in a claims attachment or when they should send them or anything about that. What would your recommendation be on educating the providers on how to do that?
MR. BARBOUR: The first thing would be that whatever roles that we come up with need to be uniformly applied across all payers.
DR. WARREN: I understand that, but I want to know who is going to educate them and in what format. Whose responsibility is it going to be to help the providers know what attachment to -- the content, not necessarily the standard.
MR. BARBOUR: I would think that the entity that wants the information is best equipped to say what the information and the content of that information should be. I would be looking to the payer industry to provide that. I would just like as much commonality in that feedback as we could get.
DR. WARREN: Would you also see them pairing up with the different professional organizations to put on sessions at conferences and things like that?
MR. BARBOUR: I know that the American Medical Association is quite comfortable doing that and reaching out to the federation to ask for their support. But there are other organizations that I know would jump up and do that as well.
MS. KLOSS: I would like to roll back to where we started this afternoon and kind of think about how the technology is changing to enable us to think about this challenge perhaps out of new frame. The requirement is under ACA that this be effective no later than 2016, so we know the technology changes will mean new opportunities. I'm sure there's been some thinking about how new payment approaches might impact claims attachment. I'd like to look ahead a little bit on those two areas, payment and technology opportunities.
MS. MEISNER: I absolutely agree. I think we always have to be looking ahead to new technologies, but I also would like to say don't throw the baby out with the bathwater. There are small docs that regardless of how sophisticated technology gets, they're going to be lucky if they can fax something. It works today for a large portion of the dental industry and for the Work Comp people who allow either FTP or direct data entry into a document management system that I would hate to see the regulation put a stop to and put them back into the dark ages because they'll go back to paper.
I do think we need to look futuristically at what technology might be coming, but I don't have a crystal ball. I think that would be hard for us to know what is this going to look like in 2016, but at least allow for expansion on that.
MS. COMBS-DYER: I would concur with Emdeon's comments. I think that there are going to be lots of new technologies that unfold between now and 2016. I'm all for trying to adopt as many of them as we can, but I also agree don't throw the baby out with the bathwater. Allow providers the opportunity to use the new technology or use the new payloads, but hang onto some of the old ones because there are some providers who still like the old way of doing things.
In terms of the new payment mechanisms, I'm not quite sure where you were going there, but I can tell you that earlier this week my area of CMS announced some new pilot programs aimed at helping to lower our improper payment rate, one of which was a prior authorization program for certain types of power mobility devices. That's new for Medicare. We've never had a mandatory prior authorization program before.
We certainly enjoyed seeing slides from Medicaid. It's looks like they do a lot of prior authorization, and there's certainly a lot that we can learn from other payers. But we certainly want to be able to accept that prior authorization documentation in an electronic way as well, so we certainly are going to be open to that.
DR. RISHEL: The first comment I want to make is that Melanie really identified one of the big missing building blocks in terms of really expansive use of the Internet in administration and clinical work. That is the ability to track digital signatures of individual providers. It's one of those things that it's not hard to do unless you try to do it at scale, and then it's never been done.
We know that DEA has a program that requires this for prescribing narcotics. We know that ONC has a staged approach first getting digital certificates for organizations and then for individuals. I know from having done work as a consultant for government agencies and being on a few committees that the hardest thing to ever recommend is collaboration among agencies of the US government. But I think this is one because the entire cost of the program is so high, the administrative complexity is so high that it's really worth putting that request out.
Melanie described things in terms of a schism between structured documents and unstructured -- structured documents were XML, unstructured documents weren't. In the attachments work there was no unstructured document. There was structured and semi-structured. In all cases even if it was a scanned image of a handwritten piece of paper from the chart, that was wrapped in the same header as structured data, including the PWK, the password, the work ID number that allows you to relate it back to a private transaction.
When I first read about ASMD, I was excited and then disappointed to see that you had chosen a format that didn't allow for that semi-structured approach. I hope as things go forward and options come you'll be able to take that into account. One of the things it does for your contractors and when it applies to claims attachment is it allows a common workflow for unstructured and structured results. You don't have to split the workflow until much farther into the organization if there's at least those couple of items of unstructured information around it.
You commented that it would be extremely expensive for your contractors to set up submission over the web. I agree primarily for a very similar set of reasons to what we talked about with respect to digital certificates. It's not really setting up secure software, it's not really being secure on the web; it's setting up the relationships with all of the people who need to submit data.
As an example, back in 2005 when Internet technology was more or less anti-diluvian, we had a couple of contractors come in and demonstrate the HL7 website setups to basically receive a request for a thing over secure email, allow the image to be uploaded over the fax, and then sent back as a CDA inside a 275.
They each claimed that they did it in less than a week, and we can pretty well verify that because we only asked them to do it a week before they demoed. The point is only that the technological ability to do that is available. It's solving the problem of identifying the submitter that is the tough issue.
One of the approaches that ONC under the current administration has brought is they brought in a bunch of the old graybeards that built the Internet and got advice from them. One of the things they really have fixed on is this modularity. Why is it that the Internet is thriving on specs that were written 20 years ago or 15 years ago? The answer is because they were little specs and they built one on the other. As a result, the effort to implement one building block is justified by returns on many subsequent capabilities built on top of it.
One such building block that ONC commissioned -- and in full disclosure, I have some pride of authorship here -- was the Direct Project. It is that little bit of being able to securely push information, securely transmit information. It doesn't say for what. It just says here's how to do it. It's in use to the best of my knowledge in about nine locations now in pilot.
As far as I know, the exchange approach with the software is in use at as many as 20 sites. They're not quite the same, but fairly equal. We have already seen organizations, nonprofits like the American Academy of Family Physicians offer to be the technological front for physicians so that the individual physicians don't have to understand the technology. They just sign up with something from the AAFP.
The notion behind that is that there's a way for, if you will, a technological wholesaler, some organization that's big enough to pass a HIPAA security audit and employ the right people and keep the doors locked and so forth can reach out and provide that support to physicians, including EHR vendors.
There are several vendors of technology, including the one that does e-prescribing, that are a resource together to this issue of identifying positions because they've been through the business of establishing a certified identity in order to do e-prescribing, and I'd like you to look at that too.
MS. COMBS-DYER: I want to comment on Direct. CMS does not currently accept in-hand Direct messages, but we are encouraging each one of our health information handlers to consider accepting Direct from their providers. Secondly, you may have misunderstood something that I said about structured. I think what I probably meant to say is semi-structured. I'm going to ask Craig to explain what it is that we actually accept.
MR. MILLER: Even in the case where we're accepting PDFs and images of the medical document, there are, in fact, either XDR or X12 wrappers on top of those that provide significant meta-data such as provider identities.
DR. SCANLON: I heard very strongly the issue of let's not make the perfect enemy of the good, but how ambitious we are in part relates to the size of the problem. I don't understand Rob and Robert's testimony. In your testimony I think it said something about 500 million attachments roughly per year.
Melanie and Chris, when you were talking about Medicare, you were more in the two million range. Either Medicare's not doing very much or the rest of the industry's doing a lot because Medicare's about a quarter of the world here. So 500 million versus two, there's a disconnect.
MS. COMBS-DYER: I can only explain the two million. That's about a million requests for medical documentation go out from our MACs and about a million go out from our recovery audit.
DR. SCANLON: That's the number that I'm more familiar with, that roughly reads about four per provider per year, which is not a big number.
MS. KOCHER: Anecdotally we had a different line of business under the Medicare fee-for-service program tell us that 16 percent of their claims had a requirement for an attachment.
DR. SUAREZ: That's 16 percent of a billion.
MS. KOCHER: We're not prepared by line of business to drill down and explain the number of percentages. It does vary by claim type and line of business.
MS. COMBS-DYER: I would also add that I only represent what we would call the medical review department, looking for those improper payments. That doesn't count the first level of appeal, the second level of appeal, the third level of appeal, and all the other types of documentations requests that a provider may get from Medicare
DR. WARREN: We're at time. Everybody needs to be back at 3:15.
(Brief Recess)
Session II: Claim (and Other) Attachment Standards and Operating rules: Current developments and Future Directions
MR. QUINN: We have three people doing parts of our presentation. Question one is being handled by Durwin Day and Jim McKinley. I'll ask the two of you guys to start, then I'll pick up with two through five.
MR. DAY: On behalf of the HL7 Workgroup we'd like to thank the committee for the opportunity to provide comments on the current status of the standards in support of attachments. I am honored to be one of the co-chairs of the HL7 Attachments Workgroup. I work for Health Care Service Corporation, which is better known as Blue Cross Blue Shield of Illinois, Texas, New Mexico and Oklahoma. We serve over 10 million subscribers, making us the largest non-for-profit health insurer and fourth largest overall in the country. HCSC has been a member of HL7 since the initial beginning of the attachment workgroup in 1996.
MR. MCKINLEY: I am also a co-chair at the HL7 Attachments Workgroup. I've worked for Blue Cross and Blue Shield of Alabama 34 years now. On my company's behalf I've been actively involved in the attachments process since 2005, and the last three years serving as the co-chair at HL7's Attachments Work Group.
MR. DAY: In response to question one talking about the current status of the standards we believe that standard of choice for the exchange of attachment information is the HL7 clinical document architecture CDA of these two. HL7 has developed a suite of electronic clinical information exchange guides, which include the Attachment Information Specifications, AIS; the Continuity of Care Document, the CCD; and the CDA Consolidated Template Guide; all of which are based on the HL7 Clinical Document Architecture Release 2 standard.
The current attachment information specifications were written using CDA, but they were created prior to the adoption of the template development. The CCD and the CDA Consolidated guides were developed using the template.
Recognizing the value of the template guides, the Attachments Workgroup is harmonizing their AIS specifications content into the CDA Consolidated template format. The purpose of this harmonization is to present to the industry one standard for delivery of a clinical document either structured or unstructured regardless of the recipient or the transport. Whenever possible we will use the same content that's found in the CDA Consolidated Guide. Wherever it's not possible the templates are usable, making development of a new guide easier, quicker and assuring harmonization.
MR. MCKINLEY: The Attachments Workgroup, in particular Durwin and I, have been participating in the development of the CDA Consolidation project. The majority of the AIS, as Durwin referred to, for the clinical reports have already been harmonized into that CDA Consolidated Guide. There is additional work in progress to harmonize the remaining Attachment Information Specifications, specifically for rehab services, medications, laboratory results and ambulance within the CDA Consolidated Guide.
The current AIS implementation guide is also being rewritten, overhauled if you will, to provide more general guidance on how to exchange attachments for requests in response in structured, unstructured scenarios, etc. The CDA Consolidated Template Guide was balloted in September, and reconciliation of that is nearing its completion.
The Attachments Workgroup with HL7 leadership support is committed to having these published and available in time for consideration in the attachments regulation. HL7 Attachments Workgroup expects to have the remaining specifications converted to templated guides within the next 15 months.
We're targeting September of 2012 for our first ballot on this new guide structured. Testing of the content can begin now with certain existing CDA consolidated document types, such as the history and physical, the operating notes and the discharge summary.
MR. QUINN: As we stated at the end of our answer on the previous question, we see the attachments technically as a standardized method for transporting information in a variety scenarios among a variety of stakeholders. For instance, attachments can and should continue to develop and be used to augment claim information, to support prior authorization of services and to complete the adjudication of claims.
The same information you get can also go beyond attachments to payer transactions. We envision the same information that is in an attachment with proper privacy and consent controls could also be suitable in effectively a backwards way to meet the requirements that we see in Meaningful Use.
As Doug Dr. Fridsma explained in the first session, in fact, the constructs we're using here are exactly the same constructs that he's using for Meaningful Use, and both really support going in both directions. So you can think of the information that's actually in an attachment can supplement a subsequent referral of a patient, for instance with controls obviously of the physician in doing that.
CDA documents as currently being developed by and for ONC provide a means for creating electronic documents for both structured -- that is partially or completed coded data -- and unstructured, for instance text. They also support attestation, electronic signature and other features that document its authorship and its support for non-repudiation. CDA is an architecture that supports many of the concepts we think of in paper documents as well in an electronic form.
They support the job of capturing all or part of a patient's clinical information for purposes of clinical care and documentation for payment. They do not, however, support concurrent and possibly complex processes surrounding clinical functions. This is to the point that documents are static in themselves. They don't support the dynamic process. We don't use them, for instance, to support a complex lab order. Those are maybe some of the same information, but it's put into messages as opposed to documents.
Finally, ONC's CDA Consolidation Project does not address procedures for requesting -- that is, soliciting -- and attachment document. At this time we have and continue to work closely with X12 to use their 277 transaction to accommodate this process as it relates to the example of a payer's response to a provider who solicits a claim status.
The set of attachment types that comprise the five current Attachment Implementation Specifications were determined from industry -- that is, payer and provider outreach and analysis -- and indicated what additional information was most commonly requested. If priority requirements for attachments are out in the industry but are not brought to the attention of HL7 Attachments Workgroup, then we wouldn't know to work on them. The industry clearly has to work with us to do that.
Currently not every attachment can be developed at once, particularly when the Attachment Workgroup continues to focus on moving existing HIPAA attachments to be aligned with current technology when a Final Rule is published. The HL7 Attachment Workgroup's message to anyone bringing forward a request to develop a new attachment type is that we absolutely want to work with them.
However, our general process for consideration of new work is, one, we have to prioritize our work. For example, federal regulations do typically seize priority. Two, the requestor must bring constituents, that is domain experts, to the process. The Attachments Workgroup does not necessarily know the requestor's business.
The requestor must be involved and agree to cosponsor the work and also be prepared to provide venues for field testing of draft standards for trial use once the initial balloting of the standards is completed. That is exactly what's happening right now with the Meaningful Use pieces required for states, too, as we're going to go into draft testing of these standards before deployment or the implementation, as we would call it, of Meaningful Use stage two.
This process has worked for attachments such as home health, prior authorization and children's preventative health services, dental, etc. These are all post-HIPAA development attachments.
As for current priorities, members of the Attachments Workgroup are analyzing the current practices by their organizations. Among the eight document types named in the CDA Consolidated Guide, the most commonly used are operative notes, discharge summary and history and physical. These document types were part of our original Clinical Reports Attachment Implementation Specifications and have been harmonized with and/or added to the CDA Consolidated Guide of ONC.
The document types named in the Attachment Implementation Specification and the CDA Consolidated Guide have discrete data elements listed that allow users to exchange clinical information that are both unstructured and structured documents. At a minimum, any needs by the industry for additional attachment types could be exchanged as an unstructured document by obtaining a LOINC code to identify the attachment type. We have a means to quickly do that.
We are currently working with Dan Vreeman at Regenstrief Institute -- Regenstrief is the author and the maintenance organization for the LOINC code set -- to commit any new attachment types into the LOINC database. We will provide the industry with the ability to implement new attachment types on a semi-annual basis without the need for changes to implementation guides. In general, we use a process called harmonization to deal with updates to terminologies like LOINC that are more streamlined than the typical ballot process that we have to use for other things.
Attachments vary greatly across the healthcare industry because provider types vary so widely. There are even extremes within an individual provider type. In short, a current status of common business rules, i.e. operating rules, for the requirement and submission of attachments in the industry does not now exist. However, it does exist in specific multiple sectors of industry such as outpatient physical therapy.
Attachments also vary by payer and provider type. For example, the payer's need for attachment can be driven by an employer's group contracts. There's a variety of pressures here. Attachments Workgroup's outreach process establishes business rules as industry domain experts are brought together with HL7 experts to develop attachments. In general, the HL7 Workgroup members do not determine content or necessary business rules. It's rather the attachment-type domain experts working with HL7 experts together working as one.
For question five, yes, HL7 in collaboration with X12 as we have done in the past. HL7 and X12 have co-developed this standard by collaboration since 1996 when we started working on this originally with CMS. Both SDOs have also jointly collaborated on many projects since that time demonstrating a clear ability to work together toward a common outcome that satisfies industry stakeholder needs. Finally, project plans, processes and liaisons to work together are already in place between HL7 and X12.
DR. WARREN: Lorraine and I were just conferring, and she was not here when you began, so if there are any other comments you want to make, you do have a little bit more time.
MR. QUINN: I think we covered everything. There's another example where we've done some fairly recent collaboration with CMS. I will bring it up because this helps. It's not just attachments where we work with CMS.
In a slightly different analysis of the technology around attachments, HL7 has also prioritized and strives to be responsive and proactive in addressing related provider and payer priority areas. For example, in January of this year an incidental connection developed between the CMS electronic submission of medical document, EsMD, project and the HL7 EHR records management evidentiary support, or RMES, project.
EsMD had developed a draft CDA low-level -- that is a level one, two within HL7 terms -- implementation guide initially intended to support tasks executed by CMS claims review contractors. One of HL7's participants was asked to contribute in two discussions about further development of more robust CDA functions for supporting EsMD incremental capabilities for expansion.
The records management evidentiary has done some pertinent work in 2009, which led to a project scope statement now being finalized with the HL7 technical steering committee -- in other words, becoming a formal project inside of HL7 -- to meet this CMS interest. The adoption of EsMD as an ONC S&I initiative demonstration, which is what Dr. Fridsma spoke of initially, this demonstrates that this small initiative is likely to inform a wide range of future projects and constituencies.
DR. WARREN: Just to give Durwin and Jim a chance, anything about the actual technical committee or comments you want to make about that?
MR. MCKINLEY: Thank you. No, I don't have any other comments at this time. I'll wait until questions.
Agenda Item: X12 – Mary Lynn Bushman and Margaret Weiker
MS. WEIKER: I'm Margaret Weiker. I'm a director at Hewlett-Packard Company and I'm also chair of the ASC X12 insurance subcommittee, or subcommittee N.
MS. BUSHMAN: I'm Mary Lynn Bushman from National Government Services. I'm a past co-chair of the Claim Attachment Workgroup at X12.
MS. WEIKER: X12 was chartered by ANSI more than 30 years ago. We develop and maintain EDI standards, technical reports and XML schemas that drive business processes globally. ASC X12 membership includes technologists and business process experts encompassing healthcare, insurance, transportation, finance, government, supply chain and other industries. For more information about X12 you can visit our website.
A brief history on attachments. I know Wes had a little bit of this in his. What is an attachment? An attachment is supplemental health documentation needed to support a specific event -- for example, a healthcare claim, an authorization, a referral -- and it's sent electronically using standardized format and content. This was a definition that was worked on and agreed to jointly by HL7 and X12 in defining what is an attachment.
As several have referenced, both X12 and HL7 began our work together in 1996, and we have been continuing to work together since then. Not only did we do work to define attachments, but to develop the actual standards and to identify the priority areas. After the initial set were developed, pilots were conducted to test the implementation of the standards and to measure ROI. If you need more information about that, Mary Lynn can speak to that since her company was involved in one of those pilots.
NPRM was published in September 2005. Obviously the standards have been updated since then. The ACA requirement is in regard to the final regulation of adopting the standards, implementation, specifications and the operating rules by 1/1/2014, and then compliance in 1/1/2016.
There has been a lot of discussion on the solicited and the unsolicited, but yet no one's worked through the flow of that. I want to make sure everybody understands when we talk about a solicited model and an unsolicited model what exactly we are talking about.
The first one I'm going to talk about is the solicited model. That's a process where the original claim is sent without any additional supporting documentation. If you look at the first lane, which is the provider and the bottom one's the payer, obviously the provider would perform a task, an office visit, they would document the service.
That, in turn, would generate an 837, which is a claim. That claim would then be sent to the health plan. The health plan would receive the claim, process it and send back the appropriate acknowledgements, the X12 999, the 277 CA, the TA1.
After it's passed those initial edits, then it goes into the adjudication system. At that point -- and it's not initially when it hits the adjudication system, but during the adjudication of that claim there will be a trigger that says I need more information this is an ambulance claim.
What happens is that gets pulled out of the adjudication and goes into a pend status. The health plan then generates an X12 277 request for additional information. You may also see that abbreviated as a 277RFAI.
That transaction is then sent back to the provider. The provider receives that 277RFAI, pulls out the LOINC code, the question of what else is needed, creates the additional information using the 275 transaction with the HL7 attachment information in it, so to speak. Many have referred to that as a wrapper.
Then once the processor receives that 275 with the HL7 document, the payer generates an X12 824 transaction, which is an acknowledgement that can be used and is used to acknowledge two different types of transactions in the transmission. The 824 can acknowledge both the X12, as well as the HL7. Then once that's done, it goes back to can I adjudicate the claim? Assuming yes, at this point you can, the payer produces an 835, and then the 835 is sent back to the provider.
The TRN segment, or the trace segment, contains the values that are used to electronically staple, so to speak, the claim to the attachment. When I as a payer send back the 277, I have assigned a trace number. When the provider sends the 275 with the attachment back to the health plan, they use that same trace number in the 275 transaction, which allows the health plan to staple the claim to the attachment.
In addition, you can send multiple attachments in one 275 transaction. X12 does recommend a limit of 64 meg, but as more and more people use the Internet, that limitation has not been as important as it was when we were doing direct connections. We had people that were doing testing as part of the pilots using dialup, so that was a concern.
In the unsolicited model the attachment is sent at the same time as the claim. In a transmission I have an 837 claim and a 275 transaction, which contains the HL7 attachment. Much of the flow is the same except obviously when the payer gets it, they're going to generate an 824 for the 275 transaction. They can also request additional information if need be, and then you have your 277 and we go through that whole cycle again.
In order to staple these transactions together there is the paperwork segment, or the PWK segment that has been referred to that's in the 837. The provider enters that number when they submit the claim, and then that same value that's in the PWK segment in the 837 is sent in the TRN segment in the 275. That way they don't get lost. They're electronically stapled together. At a very high level that's the solicited model and the unsolicited model.
In regard to the questions, one was the current status of the standards and implementation guides and what's the timing for development? The X12 version 5010 transactions are complete and ready to use. There is the 275 for the additional information to support a healthcare claim or encounter.
There's also a separate 275 guide that supports a healthcare services review transaction. That's used to support the 278 transaction, which is used for prior authorizations and referrals. There is a separate 275 guide developed for that functionality to support the 278. Functions much like the 837. Both that guide, as well as the 278, have had modifications made to it as a result of the pharmacy prior auth work that we did with NCPDP and HL7. The 277, as I mentioned before, is the request for additional information. Then you have the 824, which is the acknowledgement.
All of those stand ready to use. There are people that are using them today. We've heard from Mayo and WPS that use the 4050 versions of these. Arizona Medicaid uses the 5010 version of the 275 transaction. They don't use the 277 or the 824 transactions, but they do use the 275 transactions. Also keep in mind that not all the data resides in the health record. Some of it resides in the PMS system, which the providers are using the X12 transaction to do that.
Future. We have the version 6020, which are published, available for review right now. The comment period is still open, and we've extended the comment period 60 days in case anybody didn't hear that yet. Again, the same transactions.
When X12 discussed this and we said if we're going to recommend and adopt a specific version, which version should that be? We thought about should it be the 5010 version or the 6020 version. We're recommending to go ahead and move to the 6020 version, versus the 5010 version.
There have been significant changes made, one being with the 275 in the version 6020 it supports any type of attachment versus a specific list of attachments. The 6020 supports any type of attachment. We basically have opened up the door, so to speak. That's probably one of the big things. We've also modified and added a few more segments, and some of that had to do with the base 64 encoding in the BIN segment on that transaction. We can now support that, as well as ASC.
Next question is where you see the standards going? How are they being harmonized? Obviously the X12 standards are done as business requirements are brought forward and we incorporate those. As I mentioned before, where we're going we can support any type of attachment. What we've heard is let's not limit the attachments to what was originally proposed. Let's see what the industry really needs and let's meet the industry needs. With version 6020 you can support any type of attachment.
We also have a couple of instances where we've had the provider to payer 275 exchange, which allows the association of that claim to that attachment as well. Also we've heard about the activity in the EsMD project and using the 275 transactions, as well as some of our others.
Priority areas. Obviously we've modified to support the other attachment types. What types of business rules/areas have been brought to our attention is defining and publishing the attachment requirements in order to leverage the unsolicited business flow.
When should I send this and what should it contain? We need some rules around that. There are overlapping data elements between the 275, the claim and the attachment. If I get the same data element on the claim that I get on the attachment, which do I use? Does it make a difference?
A little bit of rules or limitations around HL7 content. Then the timeliness of the submission of the attachment. How many days should be allowed before I go ahead and just flat out deny that claim? That's from a payer's perspective obviously. The last question says yes, in collaboration with HL7, and John already spoke about that.
DR. SUAREZ: We're going to go next to Don and WEDI.
Agenda Item: WEDI – Don Bechtel
MR. BECHTEL: I'm the current chair of WEDI. I'm also a patient privacy officer for CMS Health Services. On behalf of WEDI I'd like to thank you all for the opportunity to speak today and present our comments on the subject of claim attachment standards and operating. In terms of WEDI, I think you know who we are. In the interest of time I'm going to skip this slide and move into my main points.
The main points we really want to cover today is our belief that standards development organizations write the business rules for the data content and usage of that data, and that Operating rule entities write the operation business rules not associated with the data content. Claim attachments need to be implemented to reduce the costs and time to process claims, which also benefits providers and payers.
We need to consider acknowledgements in the implementation of claim attachments. During development the SDOs have been in our opinion harmonizing those standards by their collaborative work during workgroup sessions at HL7. There's a collection of X12, NCPDP, general community people participating in that, as well as at X12 we have the same complement of people working on these standards collaboratively. We do believe this begins to bring harmonization to the various standards that we're all operating with.
In terms of the documents used for Meaningful Use exchanges today, many of those documents are CDA documents, which can easily be incorporated into the claim attachment structures that we have today. In addition to some of the other formats that are used, we believe they will also be easily accommodated in the claim attachment standard formats.
The need to support the patient information unstructured content we believe is also an important ingredient of claim attachments or the CDA Consolidated Guide with the use of link codes, as John explained. The reason for this is this is offers an opportunity to bring new claim attachment requirements forward without having to go through the development process of developing new implementation specifications and waiting for a long duration of development cycle to occur.
Also from that process we can take the opportunity to learn about the dynamics of that particularly attachment so that we can begin to rate requirements to do a more detailed specification for discrete data.
Also WEDI can be a valuable agent in identifying new or modified requirements for claim attachment standards or Operating rules. In the past WEDI has conducted numerous industry forums to talk about claim attachments to understand industry concerns or industry needs, and we would like to continue to do that to support the efforts of both entities.
WEDI will actually defer to what the SDOs have to say in terms of the status of their standards, but the point that I did want to make on this slide is that there have been several pilots, which have also been mentioned earlier, so I won't go into the details of those. The one with Empire was done with the CDA Release 1, and then there was a later one done with Mayo using CDA Release 2.
Both of these pilots were able to demonstrate that these transactions truly work and that there truly is a return in terms of reducing the time of processing and actually reducing the cost of processing. Both of those points were highlighted earlier today by those who participated in that process.
Also what they didn't talk about is there were problems identified with the use of those standards, and those problems were taken back to the SDOs. Those issues were addressed in later releases, as we just heard from Margaret. We're now hearing 6020 is now up and ready for us to consider as well.
To the question of how do we see the attachment standards going in the future and how is harmonization going to be done and use of Meaningful Use, claim attachments will continue to be needed for medical necessity and other requirements needed to help in the determination of claims payment.
We also know that there will be new attachment types required. Recently WEDI held our fall meeting this past October, and we held several sessions on claim attachments. During that time this was one of the questions that we asked about new attachment types or what kinds of attachments are being required. It gave us a chance to look at what is currently coming forward and what is still needed. We did identify a number of attachment types that might still be needed.
As I mentioned, there is harmonization going on today, and harmonization in other ways as well occurring within the SDOs and how the vocabulary sets are being used making sure that we're trying to be consistent with Meaningful Use requirements and some of the things that we see coming forward from S&I framework.
In terms of Meaningful Use, as I mentioned, the BIN segment allows for us to incorporate a number of CDA documents. Many of the CDA documents that are being used in Meaningful Use today can easily be accommodated.
In terms of high priorities, going back to our conference in October, we listened to an audience of about 400 participants and tried to gather information about what are the high-volume needs for claim attachments. Many of the things that were mentioned -- and I list here only some of them -- we found are, indeed, claim attachments that are prepared to come forward today. So no need to do development. These are ready to go, and we will begin to address industry needs almost immediately.
There are some that aren't, and those people running that committee and those sessions were members of the claim attachments workgroups from both X12 and HL7, so that list of new work items went back to their workgroups as future work to consider. This is a role that I think WEDI would like to continue to operate in to identify requirements and continue to work on how we can support these organizations.
In terms of areas not addressed and how to address them, we think the unstructured claims or attachments are the best way to address new needs. It's a way to bring forward something quickly and to learn about it, and then to be able to develop a more structured implementation. We think this is an important part of the process.
Another item that wasn't talked about today that I hadn't heard mentioned is the need for the industry to consider when new attachments are being identified where does that new data really need to go. Does it really need to go into the attachment, or does it need to go into the 837 transaction itself?
This kind of assessment was done earlier with the attachments that we have today, but going forward as we see new requirements we think this is a process that needs to continue. It needs to be a transparent process. It needs to be open to the industry. It's something that WEDI would like to continue to play a role in, as well, to help govern those choices and participate in the information gathering.
The question of what are the current standards or status of common business rules, and I think we've heard a lot of talk on this already. There really are no Operating rules today for the use of claim attachments. What we do see are implementation specifications for X12 and HL7 that really focus on the data content rules, but operational rules are clearly missing.
In addition, the attachments. We think the 997, the ASC X12 999 and the 277 and 824 acknowledgement transactions need to be used with this transaction set to be able to effectively report back to the submitter whether or not those transactions have been received, whether or not they will be process, and if during processing there were errors, what kind of errors were found so that that can all be reported back to the submitting entity.
Also note that as we heard earlier today from several of the presenters and Doug Fridsma in particular, HIEs and the Nationwide Health Information Network through the S&I framework are beginning to develop what I would call Operating rules, but they don't refer to them that way. Regular requirements for implementation of how to do these document exchanges.
We saw the Direct Project, we saw the Exchange Project identifying specific requirements that we think would typically be associated with operating rules being defined in that arena and for delivery system networks, DSNs. We also see the HIE, the integrated health enterprise, writing profiles for how to implement document exchanges within a provider network.
There are different ways that these are being documented today, but we do believe that a national Operating rules entity is still required. Those operating rules should focus on communication protocols, security requirements, hours of operation, other business issues not associated with the data content.
Those might be things like, as we've just heard Margaret talk about, defining when you should or should not send an attachment, when you should send solicited or unsolicited. Being able to have some industry commonality around these requirements would be extremely helpful.
Lastly, WEDI is not pursuing the designation of an authoring entity, but we do believe we can play a valuable role in the process. We think we can assist the SDOs and the Operating rules by helping to bring together topic forums in the industry to talk through issues that we might be having, identifying new needs, new requirements for new attachments and to provide outreach and education to the implementation process.
Lastly, before whoever the entity is that will do claim attachments as an Operating rule, the entity must be a collaborative organization that can work together with the SDOs, sit at the table together with the SDOs and do the work that needs to be done and have some clear definition between the SDOs and the Operating rule entities as to what they are responsible for so we can avoid the conflicts and actually bring forward attachments and Operating rules and implementation of specifications that work well together and allow the industry to implement these without issue. WEDI will also be available after this to answer any questions you might have.
Agenda Item: CAQH/CORE – Gwen Lohse
MS. LOHSE: Thank you for inviting me here to speak today. I'm Gwendolyn Lohse from CAQH CORE, and I'm the deputy director for CAQH and the managing director for CORE. I think people have done a fantastic job today to try not to repeat anything because it's the end of the day and I think we're all pretty tired. Just responding a little bit about the ACA requirements, where the landscape is, what CAQH CORE is committed to do, and some recommendations for moving forward.
For those of you that may know CAQH, I think many of you are familiar, but just for a few folks that aren't CAQH established CORE in 2005 to be the authoring entity for Operating rules. Prior to CORE there was no entity to do national Operating rules for the medical transactions.
We've been working with a host of SDOs to support their standards in that process. X12, HL7, NACHA, which writes the standards for the financial services industry, and also NCPDP. We want to thank the committee for recommending CAQH CORE for the eligibility and claims status Operating rules and also for the EFT and ERA.
As we think about the hearing, I think people have done already a fantastic job with this. It really is the preliminary hearing from NCVHS. There's quite a lot of work to do, and there's also quite a lot of opportunity. This whole section about the ACA is about administrative simplification and how do we get benefits and goals from that.
As we're moving forward, we're going to need to really figure out how we take advantage of this year, next year and the following year. As we've heard, we're going to have to identify the standards and the operating rules, also agree on the rationale, and then demonstrate the viability.
Across the board that's a lot to do over a pretty short period of time, so more than ever -- and I think you've already heard this too -- standards and operating rules are going to need to work together. There is a definition in the ACA and I think in the recent interim final rule for comment that went out from CMS about how operating rules and standards do work together. There's a lot of opportunity, a lot of work that has been done. How do we best take advantage of that?
Since the NPRM that has already been referenced today, there's been a lot of work to do with the standards that have been published. There's a range of standards for structured and unstructured and clinical and administrative data, also inquiries and response, and then addressing, routing and enveloping transport of data and security both at an individual level and at an organizational level.
Although the standards exist, some of them are not yet recognized. I think as NCVHS within the section 1104 you're obviously going to be recognizing the standards before there's any operating rules, so how do we start figuring out which of those standards needs to be recognized based on the priority setting, based on the rationale and based on the market maturity? As HL7 talked about, many of the authors are going through and they're ending the standards right now, so the timing is going to be very critical as we're moving forward.
There are also a lot of other business needs that need to be addressed. There's obviously a lot more focus on the web. The ONC has quite a lot of activities that could be leveraged to help with this process. We heard from EsMD today. We've actually done some pilot projects with them and demonstrations. Then we have the NHIN, which I think there were some really good questions out to the earlier committee about how can that help to get out to the providers because the providers are going to need to have the attachments and ease of use.
Then there are different business models. Linda, you had asked earlier about different business models. It is going to be leveraging what exists and how do we prioritize, but taking into consideration that there's a new world, and how might we want to approach that and take advantage of it and align resources and leverage resources. There's quite a lot of repurposing of attachments that is going on right now. How do we take advantage of that across the board?
As we're looking at this, we really have thought that leveraging clinical and admin is critical. We've already done that with some of the national operating rules that CORE has already written to date. For instance, when the CORE connectivity that was mentioned earlier, it's actually aligned up with where the NHIN is going.
How do we continue to kind of stay on that same path as we're moving forward so there's less work in the end? It's a pretty hard question to answer because given all the priorities. I think Doug Fridsma did an excellent job describing that earlier today. It is going to be tough to consider aligning them, but yet the regulation applies to HIPAA-covered entities, it doesn't apply to everyone, and we can't bite off too much. So what is appropriate to make that alignment happen?
Really the issues are multi-layered. As we think about those multi-layered issues, one of the things to consider is definitions. I think you've already heard nomenclature of definitions. There is a variance and a wide-ranging variance, so as we're moving forward, we're going to have to have agreement if we're going to have national operating rules on what those definitions are and what the nomenclature is.
And also the range of options -- there is such a host of things to do. How do we focus on the return on investment? I know many people have already referenced pilots on ROI, but there are quite a lot of things we could adopt. When it's all packaged up together, will it deliver the ROI, and how are we going to evaluate that?
Right now there's no really attachment standards that have been adopted to date by HHS, and there are also no national operating rules. We have a two-year period, if not a lot less, with no standards and no operating rules. There are business rules used between trading partners, but they're not national in scope.
We've got to make sure we have standards-setting bodies and there's a range of them. They've done a tremendous amount of work. There is not an operating rule entity, and I think you've heard from everyone today in order for the standards and the operating rules to work well together, I think everyone is recommending to have that application process start as soon as possible because that's going to really enable the industry to take the two tools, the operating rules and the standards, and see how they best work together.
I am going to go through a few examples of what could be operating rules. Before I do that, I think they relate just to how NCVHS and CMS is going to define the scope of operating rules for claims attachments. You provided a scope for EFT and ERA. You recommended standards. You recommended authors. You recommended standards-setting bodies. Then you provided some guidance, for instance, having medical and pharmacy work together to have a set of complementary operating rules.
That happened outside of your recommendation, where you made some very solid recommendations, you set the scope, then the industry collaborated. As a result, the industry's going to be able to take better advantage of the standards that exist and also alignment. As you think about how you want to advise the industry, think about what kind of scope do you want to give and how much alignment do you hope to have happen with the administrative and clinical because that's very much going to play into this.
Here are some examples of things that the operating rules could work on. It could be that based on your recommendation there are a lot of scoping discussions that occur. For instance, it could be claims only. It could be claims only attachment. It could be that prior authorization is also included. Then other types of payloads. That really is going to be up to you as to how you want to advise the industry and scope it out. Will they decide as an industry, or will you advise on that? We'll look forward to hearing from that.
Then the number of targeted services. I think the woman who presented for Medicaid today was a prime example of all the different ways in which these services could come out. Right now I think there are some high-volume priorities, but there's not necessarily a pick for the targeted services. How are we going to pick in the industry and what are the types that will be addressed?
Then structured and unstructured data. I think you've heard a lot about that today. Solicited and unsolicited and also acknowledgments. Those will be critical areas for operating rules. Payload size and limitations in data compression algorithms. Security and signature. You heard a lot about that. Then also new market models. Those are all things that would be appropriate for operating rules as we're moving forward into the attachment arena.
With regard to CAQH CORE, we are committed to work on this area. We're starting to identify during our budgeting process, which I know everyone has just gone through 2012 budgeting, how we can do a white paper and help with the process about where operating rules can focus.
We've talked to a few other entities about contributing to that process, and I think Don mentioned WEDI just held a conference and did an excellent job in identifying some of the high-level requirements. The SDOs have also done an excellent job. How do we bring that together and use resources to move forward?
We have approached HL7 with doing an MOU. We've worked closely with pharmacy on the EFT and ERA rules and want to continue to do that and recently joined the WEDI board of directors. Then we've been contributing closely with other public entities. For instance, the EsMD -- we've been working with them for over two years and contributing to the S&I framework, which will play in if the industry and the NCVHS decides we want to have more clinical admin alignment.
We have extensive experience and we'd like to apply it here where appropriate. We are going to apply if appropriate to be an authoring entity. We'll look to the NCVHS about the timing for that and the appropriateness to it, as well as look to the market. We are thinking through our budget as a result of that and have allocated resources, should we have to go through an application process if that's appropriate to do the application process, as well as be the author.
We want to keep NCVHS apprised of our work as we're moving forward both with the standards-setting bodies, as well as with the public and private work and the analysis and research. But we do advise you to pick an author because no matter who it is, there's just a real benefit to do that now to figure out the best scope so we can really take advantage of what this regulation -- this has a tremendous way to impact clinical and admin and bring administrative simplification. We need to figure out how to organize and how to leverage as soon as possible.
Agenda Item: Prior Authorization – Rx(ePA) – Tony Scheuth and Lynne Gilbertson
MR. SCHEUTH: I'm the leader of the NCPDP Prior Authorization Workflow to Transaction Task Group and I'm also the managing partner of Point of Care Partners at Health Information Technology Strategy and Management Consulting Firm. I haven't been here to testify since 2005. You haven't heard about electronic prior authorization since Doug Bell spoke in 2007. He was talking about the pilot in 2006 and some of the findings of that. What I'm going to do is fill in the blanks between then and now.
What I want to start with is what is NCPDP? NCPDP is an ANSI-accredited standards development organization, a consensus-based SDO. I think you know what NCPDP is, so in the interest of time I'm going to move forward here.
Prior authorization has become a much bigger issue since 2005 when I first spoke here. The number and instances of prior authorization have grown dramatically driven primarily by advances in medication therapy management, biotechnology, designer drugs, specialty pharmacy and the cost of the pharmacy benefit. We have more and more prior authorization today.
The impact of prior authorization is pretty dramatic and a lot of different stakeholders. I always like to start up at 11 o'clock here because the one thing that everyone in this room has in common is that we're all patients.
Prior authorization has a dramatic impact on patients in the form of hassle and treatment delay. There's also hassle at the pharmacy. The prescriber has hassles in the form of waiting for calls backs from the pharmacy. Turnaround time can be up to 48 hours. The health plans and PVMs also have efficiency challenges around prior authorization. In the interest of time I'm going to go past this particular slide.
Just a little bit of history on prior authorization. The 278 was named as part of HIPAA in August of 1996. In November of 2004 we formed the NCPDP EPA Task Group. What we did and the reason we're here is about attachments. The reason that it applies to this discussion is because what we did back then was we created a PA attachment. We did that in 2005 so that it could be pilot tested in 2006.
In 2006 we did pilot test that transaction, and coming out of 2006 one of the things that Doug talked about in 2007 is that we believe that this menagerie of different prior authorization standards -- the 278, the 275, the HL7 attachment -- in addition to the NCPDP transactions were just sort of a lot for the industry to handle.
What we did was we began to move forward and look for different solutions to prior authorization moving forward. In 2008 AHRQ retained us to look into creating one standard, and we did. The task group created a standard within NCPDP that was XML-based and did not leverage an attachment.
We did that for really two reasons. One is based on results and findings from the pilot. We felt like it was too complex to have multiple transactions. The second thing was we were aware of another finding from the pilots, and that was that we had a lot of misidentifications. We had a lot of situations where the patient was identified as having prior authorization and they weren't. Why was that the case? Because the model of providing benefit information using the NCPDP formulary and benefit standard -- we were identifying and getting information at a plan or a group level instead of at an individual patient level.
What we found were a number of misidentifications, and what the solution to that we decided would be was what we called the real-time benefit check, which I'm going to talk about on the next slide. The real-time benefit check was almost a pre-adjudication transaction that would flow between Surescripts and onto the PBM and would allow them to accurately identify whether the patient required prior authorization.
Where are we today? As per ONC earlier this year, there is no prior authorization standard, per se. There is a standard that the NCPDP created that had not been pilot tested. It is XML-based. Per earlier this year, what we needed was to pilot test the prior authorization standard.
Let me go into a little bit more about what the standard is. We have this real-time benefit check, which is XML-based, and it flows between the provider and the payer using an intermediary. Where we created the standard was the draft PA standard. What we created is a transaction between the payer and the prescriber.
The idea here is the patient visits the doctor. The physician sees the prior authorization as required or at least they suspect at the plan level that it's required. The real-time benefit check goes to the payer. That's confirmed. Once we know that the prior authorization is required, they submit a request, and we use the notion of the solicited model, the same paradigm.
We send back a form that the prescriber then fills out, an approval or denial is then sent back to the prescriber. If it's approved, then that's attached to the NCPDP script transaction, which goes to the pharmacy and then is provided and submitted when the claim is adjudicated.
Where are we today? In October of this year NCPDP had a focus group where they brought different stakeholders in electronic prior authorization to NCPDP to Scottsdale. These are the organizations that were there. We had PVMs and payers, vendors, intermediaries, physician organizations, government and other stakeholders. Really the goal of that meeting was to come out of there with pilot, was to pilot test electronic prior authorization. I think we were successful.
One of the things that we learned in that meeting that we didn't know was we knew that CVS Caremark had a pilot where they were testing prior authorization. We were aware and it was confirmed at our meeting that Caremark is not using the standard. One of the things that we learned there was that Humana with a company called Agadia is using the NCPDP prior authorization standard.
There were a couple other pilots that were talked about, RelayHealth and CoverMyMeds, as well as Medco. Both of them, RelayHealth and CoverMyMeds, were using portions or parts of the standard. Medco didn't use the NCPDP prior authorization standard, but they used the script change and status functions. We found that there is some activity going on in the industry, and we were heartened to find that the people were actually testing the standard.
What came out of that particular meeting was a few things. First of all, Caremark and Human both committed to coming back to NCPDP and working with us to modify the existing NCPDP PA standard so that it really accommodated some of the shortcomings that they discovered when they were doing their own respect pilots.
The second thing that we decided was that we would create that task group, so we would run all this through NCPDP. The third thing I really would argue or suggest that came out of that is just sort of a renewed interest and energy around prior authorization. Some time has passed -- and time seems to pass between each of those milestones -- but I would suggest that today based on some other drivers, based on that meeting there's a lot of energy around prior authorization. That's where we are today.
MS. GILBERTSON: These are other uses of attachments that you may not be aware of. One of the uses of the attachments is in what we're calling the query transactions. These are new transactions that have been approved by the membership brought forward by the industry. They are based on the syntax that's used in e-prescribing, which is script.
They are specific transactions for querying between entities. The most common use that was recommended was a pharmacy or prescriber asking the other about something, but the transactions have been built so that it doesn't really make any difference who wants to ask and who wants to be the solicitor of the information.
The use cases that were brought forward initially are the request for allergies or conditions or medical histories or, as I'll show next when we do medication therapy management, there might be a need to send all. Right now these are very broad categories because the industry needs more experience. For now this is what they've identified. They can always be added to and clarified in the future.
The query transaction allows, for example, a pharmacy to ask a prescriber please tell me about this patient's allergies. What can return back on the query response or as a follow-up query response transaction is an attachment, which is a placeholder for right now it can support either the ASTM's continuity of care record or the HL7 clinical document architecture structure.
We really don't play in the attachment space at this point, so we're not going to get into any kind of battle with who are what. Right now these are the two that were identified and brought forward.
The other use of the transactions is the medication therapy management and patient services. Most commonly you might be aware a plan might identify a population of their constituents that need a follow-up service, maybe some comprehensive medication review or maybe a targeted like a diabetes review. They can actually request in a real-time transaction to the pharmacy, for example, can you perform this service.
As part of that there is a need expressed in the industry for attachments to come forward as well. When I ask you take on this service, Mr. Pharmacy, here is some background information that I the payer can send in the transaction. The pharmacy, for example, in this case can respond back that they accept the patient. They can perform that service.
The billing is already named under HIPAA, so that's out of scope. Then there's a service documentation transaction that is a follow-up that can be related to the billing event or can be completely outside the billing event where you send the attachment. Once again, it's the same structure as the query or the first MTM service request and response. It just allows you to send an attachment of some type.
At this point if the industry only wants to send PDFs or whatever, they can send those. It's just available for that further exploration. The standards are out there. They're seeking industry entities who want to actually test all these and proceed forward.
Agenda Item: Additional Questions by the Subcommittee
DR. SUAREZ: Thank you very much. This is very informative. Thank you, everyone, for the testimony. We're going to take a few minutes for questions. For HL7 I know the work is being done in a series of priority areas that have been defined and for the most part are the more common and consistent priority areas that have been identified across the board.
Clearly the message has been somewhat consistent to say if we're going to establish a standard, let's just use it for any type of attachment. How can we reconcile that? Because ideally there would be a standard for any type of attachment, and perhaps some of the attachments are attachments for which there is not yet a defined template at CDA that can be done as a unstructured message.
But for attachments for which there is a defined template at CDA, that could be the way to submit it. How do you reconcile those? The workgroup is working on four or five priority areas, but there is a whole host of another 15. So for those other 10 for which there is no defined template at CDA, how do you see that happening or being done?
MR. DAY: Let me just clarify some of the things that you talked about. First of all, in the CDA Consolidate Guide there are nine attachment types that they have -- the CCD and the three that we have already reconciled with them. They were part of the September ballot in HL7. That's been reconciled and is finalized. We expect it to be published in December.
That will include the auth note, discharge summary, history and physical. Besides the CCD, it also includes the progress notes, procedure notes, consultation notes and unstructured ones as well. Those would be available come December in a structured or unstructured scenario.
We still have work to do, as Jim talked about, in the next 15 months to reconcile our other attachment types that we had in our original set, which include rehab services. There were about 10 different rehab therapies involved in that. We've already begun reconciling those. An interesting point is there were 24 elements that are core elements to all 10 of the therapies, so I think it's going to be not a hard task to make that into a template. The other one would be ambulance, lab results and medications.
Those are the things that we'll have to work on over the next 15 months. We have three or four things to work on in the scope of work to do, but they can all be done concurrently. They don't have to wait for one to be done, for the other one to be done and so on.
The other thing that we're working on is with Regenstrief Institute to put a section in the LOINC database to list the LOINC codes that you could send for -- you put the LOINC code in the CDA header and that would identify what is the unstructured attachment type that's in there. That could be anything like you heard Medicaid asking for consent forms for hysterectomy and so on. Those are already there, they're already built, so those could be used right now for an unstructured. There's not structured part to it. As a matter of fact, there are probably some attachment types that will never be structured.
We plan to have that built and have that out there and make it easier. The difference is we had it in a PIUC, what we called the patient information unspecified content. We had those listed there. We want to move that list from that into an external database so it's easier for people to add new ones. It would be every six months they would be able to put new LOINC codes out there.
MR. QUINN: I think it is important to remember that you're talking about a published terminology database to the country with LOINC already mapped into SNOMED as well at this point. It's not like we need to add it and then it stays in HL7 and doesn't go anywhere. We're talking about a terminology set that would be managed I assume out of the National Library of Medicine. I'll know more next Monday when we meet there.
The other thing to remember is that in as much as needs for future attachments are aligned with Meaningful Use requirements that are going out from ONC, just like we've been able to leverage tremendously what's going on so far with the consolidated ballot, there's a different high-speed track effectively inside of HL7 for that.
DR. GELZER: One quick note of a project in HL7 that Gary Dickinson is leading that I think speaks to this is the initiative for use case simplification, which is a way to capture the processes that are leading to these CDA structured documents outputs, capturing as part of that process simplifying it for future use. It's a way of perhaps not speeding a specific program forward, but speeding all future CDA developments forward.
MR. MCKINLEY: I think that one of the true value ads of moving towards this methodology is considering this LOINC database as an external code set that can be utilized by regulation to reference new attachment types or new unstructured content virtually as soon as it could be published on their semi-annual publication cycle, which we think is the baby step in getting somebody into the process.
DR. SUAREZ: Who is the maintainer of that? LOINC is.
DR. WARREN: Because they're getting into this new space, we probably need to have them come in as well and talk about some of these code sets and stuff that they're doing.
MR. MCKINLEY: We've had preliminary discussions with them to ascertain the ability to do the concept that we've talked about. We're still in the process of working those details out with them to make it more final.
DR. SUAREZ: Margaret, on your flow charts I noticed that basically the process for requesting information was through a 277. We heard a lot about the most common way of hearing about the need for additional information is a claim denial. Is that the most common way to request it?
MS. WEIKER: It goes to what's the current state versus what's the future state. I think the current state today is to deny and say I need an attachment, and I may need an attachment to an op report or the ambulance trip report or the whatever. But I think the common practice today is to report the denial of the claim on the 835 with the appropriate CARC and RARC codes.
I think going forward it would be easier in the long run to do a 277. To do an 835, you've basically taken the claim out, you've denied it, it's back out. The provider posts that denial to their accounts receivable. Then they have to work why was it denied. Now you've got somebody sitting there why was this denied. I forgot to send the ambulance trip report when I submitted the claim. Now I've got to pull the claim.
Depending on where your system is, once it denies it, you may have to go in and redo something to it. Now I've got the claim and I've got to send that electronically. Now I've got a paper form maybe. What do I do with that? I think future state we want to use that 277 because you can very specifically state with a LOINC code in that 277 that I need to the ambulance trip report. I think that's where we want to go in the future.
MS. BUSHMAN: Just to add, Walter, there are situations today where we do not deny the claim. We do request the additional information, but it's paper. So that 277 transaction would replace that paper.
MS. WEIKER: I believe Empire, now called WellPoint, had some good ROI around just the replacement of that paper with the 277.
MS. BUSHMAN: We found there was definitely a lot of benefit with just doing the 277 request for the additional information. That saved us a lot of money, and the providers that we dealt with, especially one big facility in New York, Montefiore Medical Center, who has several different sites. So when we did it, the request electronically, it allowed them to get that request timely and send the information. When we do it on paper, it never gets to the right people for them. Then their claim does get denied because we didn't receive it timely.
DR. SUAREZ: I know we have a written testimony from the American Dental Association. From the standards with respect to HL7 and X12, dental attachments would flow in the same way primarily. It's a 275 in HL7.
PARTICIPANT: From our perspective there are ADA people at all of our meetings.
PARTICIPANT: We have ADA at ours as well.
MS. KLOSS: In the first panel we had some discussion about the importance of looking at the digital signature standard as part of this. Do any of your organizations want to comment on that?
MR. QUINN: I don't have the exact nitty-gritty, but it is specifically supported in the CEA for non-repudiation and attestation on digital electronic-encrypted signature. I can get you more details, but I don't have a person in the room who has that.
MS. LOHSE: Linda, I think that's a great example of a place where you've got a wet signature, which is the typical signature, the digital certificate signature, the electronic signature. Depending upon which standards may be used, there are some variances that could be impacted on what's selected and what the operating rules could be, and also market security with regard to what is the industry really ready to do within the timeframe of the adoption depending if you going to be at an organizational or if you're going to delve down to an individual level.
We heard earlier e-prescribing obviously has some very structured signatures and requirements depending on what type of e-prescribing process you're using. It's a great question because it does go to cost and viability.
MR. QUINN: Reed, who got up and spoke to the last question, is the one who's in the middle of our MES and electronic signatures.
DR. GELZER: This is an area that's specifically within the scope of EsMD's project because the customer has required that. We're in the early stages of that. There's no doubt that there is accommodation for it functionally in the CDA construct. Without going too far down the rabbit hole, one of the questions that arises then is what is the signature authenticating? It's become a very important question in the context of EsMD.
For example, is the authenticator authenticating an extract of a record, as an example the CCD, or are we importing a digital signature to a specific document that's a construct of the native source? This is actually kind of prefacing a comment that I wanted to make about how incredibly valuable it is to have an operational function EsMD's basically as being a real-world test model for now we're establishing specific business rules for a specific end user, and we decide certain things are in scope or out of scope.
For example, one of the specific use cases we're working up is the instance where a record has been authenticated and then an error is discovered or an omission and it is authenticated a second time. That turns out to be a fairly complicated scenario. The representation of the digital signature is an important part of that because you want to obviously capture both events.
Whether you want to actually exchange both events, it offers us an opportunity to dialogue with the consumer. In this case essentially what we presented to the EsMD proponent is for the purposes of our first pass we are going to assume that what you are looking at is the final version of an amended record, and we aren't going to go down the additional rabbit holes of what do you do with the first digital signature, much less what about the case where the amendment is done by an author other than the original author.
It's a great example for how a construct that is definitely captured in a model, when you try to apply it in the real world, then you start asking additional questions. This is how we solve real-world problems. It's really a wonderful opportunity for us.
DR. CHANDERRAJ: I'm concerned with the request for additional information standards for especially the medical information for the pharmacist and the plans. I think this is expanding the scope of practice of what physicians do. We do get a lot of requests. In my day I see three or four letters from plans and pharmacies to send medical records. I see this as infringement on the practice of medicine by providers. Pharmacists and other agencies and other people trying to practice medicine -- this is expanding their scope, which is a very hard topic among all the providers in the AMA and medical societies that they're dealing with today.
MS. GILBERTSON: From a standards development organization we have to react to what the industry wants. It may not be the whole medical record, it may just be a piece. It may be, for example, allergies or conditions that are important because that receiver cannot do his function without that information. Until the industry decides to not do these things, the standards have got to be able to support the business cases to do the professional clinical information.
DR. SUAREZ: In today's world there is a practice of doing it by phone or by paper. What this is trying to do is really establish some electronic mechanism to exchange it.
DR. WARREN: That comes back to the question I asked of the first panel this afternoon of the statement that AMA made that many physicians did not understand claims attachments or what needed to be said or things like that. I think we have this very gray area about what these attachments and requests for more information are all about and how they need to be used. I think that's probably going to be a challenge. Probably somewhere in that gray area, between SDO implementation guide and operating rule.
But wherever that happens, I think we need to pay attention. At some point we need to inform everybody how all that works. I'm really concerned about that as I talk to the providers in my own area as I'm still encountering people who've never heard of Meaningful Use. They know HIPAA because that's that thing that interferes with everybody and why we can't do stuff. You really are pointing out a gray area of what's going on that we need to address with claims.
MS. DOO: I agree. Actually, I still get calls from people saying what is this thing called 5010? I just tell them to hang up and try over at another number. I have a question for all of you. That is because you all have been involved in the standards world and the operating rules and the community education and workgroup world now since 1896. I wrote that proposed rule on claims attachments, so I feel your pain too.
As I listen now to where we're going after this early afternoon session and the things that you've been talking about and that there are some that we can use, is it a different group of people that now also need to get engaged and participate in your workgroups and committees and sessions that need to be working on policy issues, that need to be doing outreach and education and policy advisory groups, that we need to be searching out and bringing on? You don't all have to answer now, but it would be great to have the input.
MS. LOHSE: I would immediately say yes, and that's going to be a critical part of the planning and execution process. There are state regulations to be considered, some of those other things, IHE, so absolutely. It's a great question.
MR. QUINN: This goes to the question we raised in our presentation that said if somebody needs an attachment, we need an expert to tell us exactly what do you need because if you leave it to us to guess, we probably won't get it right. We can do the technology piece, but the content piece really seriously -- there are a lot of domain experts that sit inside of HL7, but to say that I've got the right one for somebody's request for an attachment when it's not part of the general things we expect today like a lab result, then absolutely we need help.
MS. WEIKER: To your point, you need both sides of the house, so to speak. You need the provider and you need the health plan because it's typically a health plan that will come first and say I need an attachment for this or I want to do this via an attachment. But what they may not realize is the information where it sits, how a provider would even get the information, or is it more clinical? If it's clinical, what are you really going to do with it?
It's one thing to say let's just get all the payers around and figure out what we want to do with attachments and come up with rules. You also have to get the other side with the providers with does it even make sense to gather that information? Are you gathering it and does it make sense, and if you do, what are you going to do with it?
DR. WARREN: Which brings the next question: how do we get all these very busy at the table? How do you get the SDOs to get the providers and the health plans and whoever else is in the game to help work on the standard? I think that's going to be challenging.
MR. BECHTEL: We've been working on that issue for a long time in the SDOs. At WEDI we are trying to reach out and do more outreach to the industry at large and identify the issues that we're trying to solve. I think through that process we can find people that want to get engaged in this work. Then we can direct them to the SDOs or we can use them within WEDI and the other associations. We're all trying to do this. We need to all work together to try to bring the right constituents to the table all the time. It's constant.
DR. WARREN: When I was really active in patient care, technical committee, that was one of the challenges we always had is we needed to get the people actually providing care there. We might be able to bring them in once. They'd be so overwhelmed by the SDO process that we'd never see them again.
MR. QUINN: One of the things that clearly has been part of the HITECH Act was the grant to promote the creation of informatics programs. The good news going forward is that people coming out of school that are physicians, pharmacists, nurses, the caregivers will more likely have a better understanding of information technology.
It won't be so rare for us to find somebody who basically went all the way through, got an MD, and then decided they didn't really want to take care of patients, they wanted to work on IT instead and build computers. We've got lots of those in HL7, but they really do seem like a strange turn in the typical path of education to profession.
MS. WEIKER: Sometimes you can convert them. The anesthesiologists with X12 we had an issue with. We finally got them to the table, and now they come to every meeting, they participate, they speak, they go from this group to this group now. They realize the importance of being there. But sometimes it's just getting them there, getting the right person. If they have a business driver, it's as Lynne said, threat and opportunity, they'll get there and they will get involved. You take one specialty at a time and look how long that would take.
DR. WARREN: -- some success in patient care with the pediatric organization. They actually designated people to come. They were very helpful, pediatricians.
MS. LOHSE: I would hope it's a great example of why clinical and admin would want to coordinate on this because there's been a lot of outreach that the clinical world has done. How can that coordinated messaging happen because of attachments playing in both worlds?
MS. GILBERTSON: While each of the organizations does have face-to-face meetings three, four, five times a year or whatever it is, we are on conference calls with non-members and members every single day. I don't know about the other organizations, but the NCPDP task groups, which is the work between the meetings, we have 70-80 different task groups going on, and they're open to any interested party who wants to help us solve the problem. Any day of the week you could be on five or six conference calls if you're interested. But that negates the having to show face-to-face because hopefully the worker bees are getting the ideas out on the table each week.
MS. DOO: In this day and age CORE does that and X12 does that.
DR. CHANDERRAJ: Because of the nonparticipation of the physicians, I think we as a body should be fair to everybody and not somehow because of their nonparticipation, the end user, the provider is being burdened with so many of these regulations without realizing what impact it makes. AMA represents only 15 percent of the population of physicians. I think so many regulations are being imposed every day.
The simple outlet of simvastatin at 80 milligrams, I get six or ten denials by the pharmacy every day, and these patients have been using the same does for their required medical condition for years. Now I have to answer all these questions. What I'm trying to say it because of the nonparticipation, we should try to look at the provider aspect, the end user aspect and be fair to everybody taking all these factors into consideration.
DR. SUAREZ: That's one of the most difficult challenges to try to get the practitioner, the physician themselves participating in this discussion. We're ready to wrap up. I want to say on behalf of the committee thank you all for this very engaging discussion. Since the very beginning when we started to plan the idea of having a hearing on claim attachments, we thought it would be an important one to have, and we really proved that today that it was very significant and valuable to have you all come and let us know where things are. Thank you again on behalf of the committee.
We will be putting together some of the observations. I don't know that we will have any recommendations formally. We do understand the importance of identifying an authoring entity early in the process, so we will be moving in that direction very quickly as well.
Again, thank you everyone, all of the people that are behind us here that attended as well for sticking with us. Have a wonderful rest of the afternoon.
(Whereupon, the meeting adjourned 5:35 p.m.)