[This Transcript is Unedited]
Hubert H. Humphrey Building
Room 705A
200 Independence Avenue, S.W.
Washington, D.C. 20201
DR. COHN: Good morning. I want to call the meeting to order. This is the first of two days of hearings of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics.
The National Committee is the main public advisory committee of HHS on issues of health information policy and GPRA has a major role in HIPAA administrative simplification and implementation.
I am Simon Cohn, chairman of the Subcommittee and I would certainly welcome the subcommittee members, HHS staff, other interested parties and, of course, those on the Internet. I actually will remind everyone as we proceed through the day that we are on the Internet and, therefore, would ask everyone to speak both into the microphone, identify yourself and also make sure to speak clearly, which is something I will also keep reminding myself to do as we proceed on.
Now, the focus of the hearings over the next two days and especially today is on administrative simplification. The purpose of the administrative simplification provisions of HIPAA are to improve the efficiency and effectiveness of the health care system by establishing standards and requirements for electronic transmission of certain health information.
The role of the NCVHS and this subcommittee in HIPAA are twofold. First of all, in complying with HIPAA administrative simplification, the Secretary is to rely on recommendations of the NCVHS and then certainly pertinent today is that the NCVHS has been asked to track implementation for both HHS and Congress and identify implementation issues and barriers and recommend ways to mitigate these issues.
Now, the purpose of the hearings today is to talk with representatives from various health care industry segments, to learn the problems that are impairing the implementation and possibly tools and solutions to the issues that have been identified. Obviously, this testimony will help us develop sound informed recommendations for the Secretary.
Now, let me just review before we go into introductions very briefly what we are going to be doing today. We are going to start with hearings first from HHS and then talking with the DSMOs in understanding the status of the DSMO web site and the progress of your activity. Then we will be moving into hearings and panels for the rest of the day, identifying issues, understanding sort of the status of the industry in relationship to implementation and identification of issues.
Finally, late in the afternoon, we will have a session on electronic and digital signature. Tomorrow, we will be talking about PMRI standards and then talking about the annual report to Congress.
With that, why don't we have introductions around the table and then after that we will go around the room with the microphones to capture who is here and please state your name and affiliation.
MS. TRUDEL: Karen Trudel with the Health Care Financing Administration, staff to the subcommittee.
MS. FYFFE: Kathleen Fyffe. I work for the Health Insurance Association of America and I am a member of the subcommittee.
MS. GREENBERG: Marjorie Greenberg from the National Center for Health Statistics, CDC, and I am executive secretary to the committee.
MS. BEBEE: Suzie Bebee with the National Center for Health Statistics and staff to the subcommittee.
DR. BALL: Judy Ball from the Substance Abuse and Mental Health Services Administration and I am staff to the subcommittee.
MS. WARD: Maria Ward with First Consulting Group and I am a co-chair of the DSMO Committee.
MS. WEIKER: Margaret Weiker, EDS. I am chair of the DSMO.
DR. FITZMAURICE: Michael Fitzmaurice, Agency for Health Care Research and Quality, liaison to the National Committee and staff to the subcommittee.
DR. ZUBELDIA: Kepa Zubeldia with Claredi Corporation and member of the committee.
MR. SCANLON: I am Jim Scanlon from the Office of the Assistant Secretary for Planning and Evaluation. I am executive staff director for the committee.
DR. COHN: I am Simon Cohn. I am with Kaiser Permanente and chair of the subcommittee.
May we have introductions around the room, please, with the microphone.
MR. STANIEC: Dan Staniec from the National Council for Prescription Drug Programs.
MR. TRUPELLO: Anthony Trupello, Trust Data Solutions.
MS. JACKSON: Debbie Jackson, NCHS.
MS. PAYTON: Patricia Payton, Health Care Financing Administration.
MS. WHEELER: Gladys Wheeler, Health Care Financing Administration
MS. WILLIAMSON: Michelle Williamson, National Center for Health Statistics.
MS. EMERSON: Mary Emerson, Health Care Financing Administration.
MR. ZUCKERMAN: Alan Zuckerman, Georgetown University.
MR. SIRAKOWSKI: Art Sirakowski. I am with the Center for Devices and Radiological Health of the Food and Drug Administration.
MR. KAISER: Jack Kaiser with the Academy of Managed Care Pharmacy.
MR. MOERTEL: Dave Moertel from the Mayo Foundation, today representing a consortium of providers.
MR. MC LAUGHLIN: Mark McLaughlin, McKessonHBOC.
MR. LYMAN: Dick Lyman, Health Care Financing Administration.
MS. CAPP: Sharon Capp, Center for Devices and Radiological Health.
MR. WEIN: Eric Wein, Social Security Administration.
MS. DEAN: Roberta Dean, Health Care Distribution Management Association.
MR. ROBEY: Thomas Robey, Centers for Device and Radiological Health.
MS. CARLSON: Rebecca Carlson from the American College of Radiology.
MR. RODIE: Dan Rodie from the American Health Information Management Association.
MS. ADAMS: Heidi Adams, Health Care Financing Administration.
MR. BASS: Steve Bass with Washington Publishing Company.
MS. ALT: Vivian Alt, National Library of Medicine.
MS. WHITE: Tracy White, NCHS.
MS. ADLER: Jackie Adler, NCHS.
DR. COHN: I think our first briefing is from Karen Trudel and Jim Scanlon on the status of HIPAA implementation.
MS. TRUDEL: Thank you. I am just going to briefly go over the status of the HIPAA regulations.
To recap a little, everyone knows the first final rule for the transactions in code sets was published in August of last year and became effective in October, which started the two year implementation clock, which will end in October of 2002.
We also published several technical corrections on November 24th of last year and we are in the process of updating the rules to revise some of the references to the MCTDT standard that is in progress now. One example is that through an oversight the standard that we adopted for the batch standard does not match the standard that we adopted for the interactive claim.
We are also working on the proposed rule for attachments, claims attachments, and that notice of proposed rulemaking is expected to go into clearance at HCFA early this month. We are preparing the final review package right now. The national provider identifier and national employer identifier final rules are in department clearance. The plan identifier proposed rule is in HCFA. The development is continuing on that at this time.
The security rule is also being completed at HCFA. We expect to begin that clearance process later this month. Part of this rule, of course, was published on December 28th of last year and we are awaiting clarification from OMB to find out whether the effective data of that rule has been postponed by the new Executive Order, which placed a hold on regulations so that they can be reviewed by the incoming administration.
We are again beginning to work on enforcement. An NPRM proposed rule is being drafted and we do anticipate that that will be published sometime later this year. As I said, there is a temporary hold on sending regulations to the Federal Register and we expect that that will be lifted at some point in the relatively near future, but we can't predict exactly when that will be.
So, the final rules that are still in process may be held until that process is completed.
The Secretary does have the authority based on the statute to amend regulations within the first year, if needed, to facilitate the implementation of the standards. One of the things that we will be listening to very hard today is the extent to whether that kind of an amendment will be needed for the transactions and code sets and also, of course, the Secretary can amend standards annually thereafter.
That concludes my briefing.
MR. SCANLON: Just to add, the HHS Secretary designate is Governor Tommy Thompson from Wisconsin. He will actually be arriving today and taking office today and tomorrow, I think, at about 11 o'clock in the Great Hall on the first floor, there will be some sort of a greeting ceremony. I think he will be sworn in later today.
So, the Executive Order that Karen referred to basically -- and this is common with any new administration to sort of slow down and freeze the regulatory process so that the new leadership can take a look at the regulations. Once the Secretary is on board, presumably -- the Executive Order indicates that the regs are to be looked at by the new appointees. So, once we actually have a Secretary, things should begin to move presumably forward again.
But, again, this is common at the beginning of an administration, to look at all of the recent regulatory issuances, to look at any pending regulations, to look at any regulations and development to kind of give a close look. So, presumably, the Secretary, the new Secretary Thompson will be here tomorrow and we should be in business then with the regs and so on.
DR. COHN: Any questions from the subcommittee?
Kathleen.
MS. FYFFE: Given that the White House memorandum came out about the regulatory review, is there then likely going to be another sort of official document that comes out and says these regs are on hold -- I mean, is there going to be some sort of follow-up action that would be published in the Federal Register or what might likely be the next step?
MR. SCANLON: I don't think anyone knows yet. All of the -- every agency in the Executive Branch has been asked to identify regulatory actions that fit that Executive Order and to report those to OMB. My guess is that the new leadership will look through all of those on a case by case basis to decide whether to let them proceed to ask for additional time for review or to hold them up and look at them again.
My guess is there would be some formal announcement subsequently about which ones will proceed. Some of them clearly, you know, won't be held up for very long. They will just be -- there will be a look by the new administration and then they will be let go.
Others, I think there may be concerns about and I think things would have to be worked through. All the agencies would brief OMB on the new leadership on any regulatory proposals that are in development. Now, we do that at any rate. We prepare a regulatory plan every year. So, this will be put together really quickly. But that will be an OMB decision and a White House decision and I think the Secretary would weigh in, but hopefully within a few weeks we would begin to see action.
MS. FYFFE: The concern that I see with this is the message that it sends to the industry, that things could be slowed down and if they are not slowed then we need to communicate that very, very strongly and widely.
MR. SCANLON: Actually, if the industry wanted to convey that notion to the White House, that wouldn't hurt -- that the big industry is eager to see these proceed wouldn't hurt the effort.
DR. COHN: Other questions or comments? Actually, Jeff, you have arrived since we have done introductions. Would you like to introduce yourself as a subcommittee member?
MR. BLAIR: Jeff Blair of the Medical Records Institute and a member of the subcommittee.
DR. COHN: Thank you.
Any other questions or comments in relationship to the briefing?
[There was no response.]
Okay. With that, why don't we proceed on to the briefing from the Designated Standard Maintenance Organizations. Margaret, do you want to lead off this discussion?
MS. WEIKER: Yes. As I stated earlier, I am Margaret Weiker with EDS. I am the DSMO chair and NCPDP liaison to the DSMO.
MS. WARD: Hi. My name is Maria Ward. I am with First Consulting Group and I co-chair the DSMO Steering Committee, along with Margaret. We wanted both to say thank you and, you know, thank you for the opportunity to come here and talk about this process today.
What we are going to do, just so you know our process for the next half an hour, is spend a couple of minutes talking to you about the questions that you have asked and going through this written testimony here and then Margaret is going to give a demonstration of the web site and then, hopefully, that will allow some time for questions and dialogue afterwards.
Just getting started, good morning, and thank you for the opportunity to update the NCHS on this very important process. Before we begin the demonstration of the DSMO web site, I would like to give a progress report and answer your questions. If the committee is interested in each individual organization's response to the complete set of questions, they are provided on the diskette.
The first question: How has the overall DSMO change process been working or not working; for example, early examples of requests to date, how were they processed, who handled them, et cetera?
The process is still in the early stages of use with only two batches of requests being received. However, the use of the web site, the notification of calendar events and the processing of change requests have gone well. I have included the first batch of change requests.
What you have on the next about two and a half pages is the actual first batch of requests that was entered from the public into the DSMO web site in December, which was the first live batch that we had. I think in the interest of time, we are not going to go through, unless, Simon, you prefer to, we weren't planning on going through each of these requests on an individual basis, but just provided them for you so we can get a sense of what kinds of things, what sort of activity we are seeing on this web site and then maybe just to summarize and bring some things to the top for you, in that first batch, there were five requests and of them one of them is really just -- it was a question. It was sort of misdirected. It wasn't a request for change. It was somebody who was asking a question about coordination of benefits.
So, we are starting to see that kind of thing, where folks might just be saying let's send it to these people at the DSMO and see if we can get an answer. We saw that with the first one, but interestingly three of the other four were related to code sets. They weren't actually related to data element usage or data element, you know, presence or absence of the implementation guides. They are related to code sets, NDC codes and HIEC codes.
So, that was really, in summary, the first batch that we saw in December heavily related to code sets. Again, you have the details of that if you are interested in reading that.
The second question that you asked us: How has the DSMO process impacted your organizational relationships with other SDOs as it relates to HIPAA implementation?
The DSMO process has served to increase the opportunities each of the organizations has had to interact with one another. The development of this process has lead the DSMO organizations to become involved in each other's specific industry-related efforts, to further open the lines of communication and to provide support for one another with respect to activities related to the DSMO, as well as those that aren't.
How has the DSMO process changed your organization's internal request processes, i.e., what internal process has been added or modified to address HIPAA implementation issues?
To summarize, two organizations, HL7 and NCPDP, had to modify current processes and four organizations, X12N, NUBC, NUCC and DeCC, had to develop processes. For further information, I have included the four responses received from each organization.
First -- and you are going to see now four responses here. The first is from ASC X12N. The X12N Insurance Subcommittee has established the HIPAA Implementation and Coordination Workgroup, X12N Task Group 3/Workgroup 3, to document and coordinate issues and activities related to HIPAA. These include the review of the DSMO Memorandum of Understanding and the coordination of the change management process within X12N in conjunction with the implementation guide authoring workgroups.
The HIPAA Implementation and Coordination Workgroup is currently documenting the procedures in support of the CRS, which is actually the initials for Change Request System, which is a DSMO web site, which will be posted on our implementation guide web site.
The DeCC, the Dental Content Committee of the American Dental Association, first met in September 2000 and completed an initial review of draft operating procedures. A revised draft, modified to reflect the discussion and constructive critique at the committee's first meeting, has been prepared and delivered to all designated member organization representatives.
The next DeCC meeting is on February 16, 2001 and this meeting's primary focus is adoption of the revised draft operating procedures. Upon adoption of its operating procedures, the Dental Content Committee of the American Dental Association will be enabled to take formal action on requests concerning HIPAA standards that arise through the DSMO change process.
HL7's response: Within HL7 we had already begun to develop an internal change request process to accommodate those who approached us with attachment development needs. As we entered into discussions related to the MOU and the DSMO process began to take shape, we examined the process already in development and made all necessary modifications.
One significant consideration was to create a process that supported the time frames established for developing recommendations in accordance with the MOU. Key factors for success include tremendous support from HL7 headquarters as it relates to building databases and web-enabled solutions to facilitate communication, establishing list serves, hosting conference calls, as well as administrative support for any manual processes. The documents detailing the process are included on the diskette and available at the HL7 web site.
NCPDP: NCPDP's Standards Development Process has been modified to include the Change Request process. NCPDP's change systems, Data Element Request Form, called the DERF, process has been updated to reflect recording and tracking a change through the Change Request System. NCPDP's membership reviewed the updated documentation and charts on this process. If a change is requested to a HIPAA named transaction set via NCPDP's DERF process, the change is denoted ont he DSMO CRS web site and processed through that system. The DSMO CRS web site is updated as NCPDP's membership processes the DERF requests through their standard operating procedures. The document detailing the process is included on the diskette and available at the NCPDP's web site.
What impact has the Errata Workgroup in X12 had to date on the DSMO process? To date, the impact appears to be that there may be confusion in the industry as to what is an appropriate entry for the errata web site versus an appropriate entry for the DSMO web site. The confusion comes in primarily with the distinction that the errata effort was strictly aimed at addressing the X12 004010 version of the implementation guides and the DSMO process addresses changes to future versions of these guides. As the errata process moves forward and decisions are made regarding entries on that web site, the result could lead to those entries being forwarded to the DSMOs Internet he form of change requests.
What recommendations do you to improve the DSMO process? Improved education at the industry level of the DSMO process. This could include HHS incorporating information about the DSMO process on the administrative simplification web site and including discussion of it when presenting general HIPAA information at industry events.
Continue to improve the communication between government and the DSMO Committee; for example, HIPAA-related efforts underway with HHS that might affect work in progress either with regard to the DSMO process or the respective member organizations.
Funding for the DSMO web site is needed if we are to make it a robust, fully functional web site. Each DSMO member has already provided $5,000 for the development of the site and the WEDI Foundation has agreed to fund the ongoing maintenance costs. All organizations agree that there should be government funding to improve and maintain the site.
Funding could also be used to accomplish the educational effort recommended above. If members of the DSMO were able to educate the public on this topic at the appropriate venues, it would contribute to the successful and timely implementation of the standards. This is not achievable when the organizations that employ these volunteers are expected to absorb the cost of such activities.
MS. WEIKER: I am now going to go ahead and give a demonstration, as time allows, of the actual web site. The first screen that you come into is basically a very high level overview of what is HIPAA. This is the second screen that you come into that actually talks about the Change Request System.
On the screen are the URLs for each of the six DSMO organizations. There is also a link to the frequently asked questions because as Maria mentioned, the first actual request entered was really a question and should have been put in the FAQ site. Also per the MOU that was signed, there are links to the Washington Publishing Company's web site, where you can receive the X12N implementation guides and there is also a link to NCPDP's web site where you can get those implementation guides.
In addition, there is an overview of the process that you can click onto. There are instructions for sending in paper requests. There is a privacy policy that we have posted and we also have established a link to WEDI. As Maria also mentioned, the WEDI Foundation has agreed to fund the ongoing cost at this point in time. That is evaluated on a yearly basis with whether they will continue to provide that funding.
So, you log into the system and I have done so. Because of my access authority in the Change Request System, you will see an SDO area and as a general public person actually logging into this, they wouldn't see the SDO area. You can request a change. The first step of that is a drop down box, where you actually go in to which standard you want to change. There are all the X12. There is NCPDPs that is labeled retail pharmacy. Claim attachments are also listed as well. Then there is the overall HIPAA policy, where maybe somebody is requesting that we consider a new transaction be added as part of HIPAA.
So, I am going to click on "Retail Pharmacy Claim." No matter which item you initially click on, the first several screens will be the same for each of them, whether it is an X12N, NCPDP, HL7, HIPAA policy type of question. These screens will be the same and ask basically for the same information.
So, you would have to enter what is your business case for this change request. Then if it is a particular to a standard that already exists, what page number, segment, data element, code values, trying to get the requester to narrow down what their actual change is.
Then I am assigned a change request number and it tells me that I have to complete additional information to actually enter an NCPDP request. HL7 also has, once we get to this point, where they require additional information to process the change request. If it is an X12N change request, it ends at this point.
What NCPDP has done, as well as HL7, is we have incorporated our existing change request, as NCPDP calls it and Maria mentioned it, a DERF. We have actually incorporated those requirements that we need to process a change request into the web site. So, I am going to change an existing data element. I am encrypting it. You enter the field number, the I.D., the name.
Now, at this point it has accepted my change. I can print a, quote, printable copy so I can have it for my records. I can withdraw my change request. Initially, the second batch we had, there was a request that was put out by the state Medicaid group in regard to attachments. However, they withdrew their request.
I can view my request. I can also view the monthly batches. So, I can go in and I can see here is February 2001 batches. I can look at December's, as well as January's batches. This is what was in it for January. As I mentioned earlier, the one that Gail Lowry submitted for claim attachment she withdrew.
Then there are two other change requests that were entered in regard to the institutional claim. I can also go into the SDO area. Here in the ten day window, I can express interest. Since I am set up for the NCPDP, I would go in and say whether NCPDP is interested in doing the business analysis, as well as technical analysis, or I can express no interest.
MR. SCANLON: Can you change your mind?
MS. WEIKER: No. I cannot change my mind. Once I say I am going to express interest or not express interest, I cannot change my mind.
There is still one left. This is actually a develop site. I can also go in and actually view all the requests that have been entered into the site. So, it is basically a compilation of all the requests and it is not done by the actual month.
As you can see, there were 14 entered at this point in time and I can see who is expressing interest in those. So, as a requester, I can go out and say, okay, for example, I entered this institutional claim UB92 request and I can see which organizations actually expressed interest in developing a solution to that problem.
There is also a calendar that is available for the individuals. The calendar on the left, the actual monthly calendar shows the days. For instance, February 7th, that is the 5th business day of the month. So, that is basically when the February batch is completed and those are batched together and sent.
The 22nd is the day that the DSMOs or the organizations that make up the DSMOs actually have to go through and express interest or not. The meeting schedules of the organizations, HL7s, X12s, there is the NUBC, the NUCC and NCPDP -- so, if I know that NCPDP, for example, has expressed interest, this is where this is going to be discussed -- I am not sure if you can see that clear at the bottom -- or HL7 or any of these, I can see where they are going to be meeting those type of things.
The site has been functioning very well. There are a few little tweaks that we still need to make, as it is a learning curve, ongoing process. I know when the person that entered the actual claim attachment request was going through all of the screens that you can go through, he was like, gee, it would have been nice if I knew what Question 20 was when I answered Question 2. So, we are making an enhancement to the site to where a requester can actually download a PDF file to see what all of the questions are before they actually enter a request.
So, that concludes the demonstration of the site at this point. So, Maria and I will entertain any questions at this point.
DR. COHN: Questions from the subcommittee? Let me lead off with one here that sort of comes to mind.
Obviously, this whole process is new and first I want to congratulate you on the progress that you have made. I was actually reviewing the minutes from the subcommittee from the end of I think it was March of last year where we sort of celebrated the beginning of this process and the signing of the MOU. It is very exciting to see this much progress being made.
Yet, obviously, there is going to be a lot of needs coming up in relationship to the transactions and the implementation. Now, it is pretty clear to me the role of the DSMO group in relationship to ongoing maintenance, as well as of expansion of the standards. I am a little less clear in my own mind about the role of the DSMOs in relationship to this first likely to be changed in the final rules that are stated for no later than October of this year in relationship to industry input.
Can you maybe give me some of your views about what you believe is the role of the DSMO process and activities in relationship to that?
MS. WEIKER: At this point in time, HHS serves as a non-voting liaison to the DSMO and we are working with HHS at this point to determine basically some criteria with what is a modification, which would be like a technical correction to a guide and would that have to go through the DSMO process versus what is a maintenance to a guide. I need to increase the number of repetitions of a segment. I need to change a data element in X12N from situational to required or vice-versa, those type of things.
There was language that was in the final rule on standards and code sets that explained the maintenance modification. What we are doing is working with Mary Emerson and Stanley Nockison(?) with HCFA to determine exactly definitions of those, clearcut definitions to where everybody in the industry would understand and then also does it go through the DSMO process, does it just go through HHS regulatory process or does it go through an SDO-defined process.
But we are working through that right now with them and, hopefully -- in February, we have another meeting and we will get that decided at this time.
DR. COHN: How often are you meeting?
MS. WEIKER: We are meeting right now once a month per the MOU unless there is an emergency or something like that. We have in our last meeting discussed this with them. There was some modifications, comments. I believe today Mary will be discussing some of that today as well.
So, by February we hope to have it all finalized so we know that, for example, a question was asked about the errata. What, if any, of the errata has to go through the DSMO site or does it just go through the SDO site, those type of things.
DR. COHN: Jeff.
MR. BLAIR: Could you help me understand if there is a difference in the way things are handled with the health claim attachments because it is my understanding that that hasn't been released as a NPRM yet?
MS. WARD: Jeff, this is Maria.
My role actually in HL7 is to co-chair that workgroup, the Claims Attachment Workgroup. So, from that perspective, I am very familiar all of the work we have been doing with HHS on that as well.
No, we don't have a different path or a different process to handle issues that arise related to claims attachments. In HL7, we made the decision, even though our NPRM had not been published yet, we made the decision that we would contribute all of our work, as well as the other SDOs have, those that have already been named in the final rule, we would as well contribute all of our work and our participation and our efforts to this process.
So, as we go forward in developing and working in HL7 for claims attachments, we are doing that on a consensus industry-based process and forwarding all of that through the DSMO so that everybody has an equal opportunity to have input to that development as well, even though we haven't had an NPRM published yet, it is more an effort on HL7's part to say we are going to be an equal player in all of this as well. We are not off doing our own thing in HL7.
MR. BLAIR: I think it is a very good idea. I just didn't know the process --
MS. WARD: For all intents and purposes, we are at the table equally in our development process with everybody else.
DR. COHN: Jim.
MR. SCANLON: You have included a couple of recommendations to improve the process and the web site and the first one relates to the -- I think a link between the web site here and I think you are referring to the HHS administrative -- we don't have a link now so that we could -- it referred to a simple link or some description in --
MS. WARD: No, there is no link at this point.
MS. WEIKER: It may be even more helpful to do more than a link, but actually some sort of a descriptive -- there is a link on the very first page, which doesn't show in the demo that to the admin sim site, but there is no link in the admin sim site to our site.
MS. WARD: And maybe even expanding a little bit
-- and certainly that admin sim site gets a whole lot more activity than our web site does. So, to have more of a narrative description and explanation of what that process is, our experiences in our day jobs when we were working with clients and people in industry has been the folks don't even know that this exists, let alone how it works or what it is for.
MR. SCANLON: I think we would be very receptive to work some language out with you on the coding.
DR. COHN: Kepa.
DR. ZUBELDIA: You are getting some noise in the questions already. People are confused and they may be asking you a question and you have to answer or they may be sending an errata that doesn't go out to the site. With a link like that, you are going to get -- you will get a lot more noise. Do you have a process to filter the noise? Do you have a process to answer the questions, which one of the DSMOs answers questions or to brief out the questions and what is the process for that?
MS. WEIKER: There is a FAQ section on this web site, as well as the CSR. Each organization -- it is a lot like when you entered a change request. I have a question for claims attachment. I have a question on NCPDP. I have a question on X12N. Each organization has established a mechanism to actually answer those questions. In regard to the first change request, which was actually a question, X12N will be addressing that and answering that particular question.
But each organization has a process to answer any questions that are entered, either on the FAQ side or as entered on the CRS side.
DR. ZUBELDIA: So, if I send a question to the DSMO side, I may get multiple answers and they may be conflicting.
MS. WEIKER: If you go into the actual FAQ site and enter a question, you can only -- it is a lot like the drop down menu. I am going to answer an eligibility question. That automatically gets funneled to X12N. NCPDP doesn't see the eligibility question because it is not our standard.
If for some reason like the 835, which is the remittance advice, which NCPDP is going to use, as well as X12, and if somebody answered a form that asked a pharmacy-related type of question for the 835, X12 would forward that to me and then I would answer and give it back to them. So, there is a process. You don't opt in to the FAQs, like you did for the change requests.
DR. COHN: Marjorie.
MS. GREENBERG: I wondered what the relationship is between questions of your site and then the questions that are coming to the administrative simplification site and if there is some coordination there or some possibility for duplication.
MS. WARD: Let me take a stab at that. As Margaret mentioned, HHS has an non-voting position on the steering committee. So, they are in all of the conference calls and they are involved in all the work we are doing, as we discuss how to respond to questions on the FAQ or questions that might come in to the CRS.
The questions that come out onto the FAQ, the requester actually has the opportunity to say is this a policy question, is this a question for the NUBC, NUCC. If those are tagged as policy questions, they are routed directly to the Department through the individual who sits on the steering committee with the DSMO. So, there is a direct coordination there with the Department on all of that.
That is one of the areas we recognized early on. There are FAQs everywhere and we are trying to coordinate with the Department in being able to centralize some of that and consistent answers to those questions.
DR. COHN: Other questions?
Karen.
MS. TRUDEL: From speaking with various people throughout the industry, I get the impression that once the X12 errata process is completed and people have had a chance to fully look through the implementation guides and work out what they believe the changes should be, that there is going to be an onslaught of change requests. I want to get a sense of whether you agree with that and if that does occur and if the Department determines that there is a need to amend the standards within the first year, how is the DSMO process and the timetable geared up to help us do that in a timely basis?
MS. WEIKER: There may or may not be an onslaught. That is kind of hard to tell at this point. There was a lot of errata that was entered. However, a lot of it had to do with typos, et cetera. There was errata that was entered that shouldn't have been entered as errata. It was actually a change request.
The site is ready to go, up and functional. It can handle as many requests as we get. In regard to basically can we fast track something, I believe is where you are after and we talked about that at our last meeting because there is the five day, the ten day and then there is the 90 day process. Where we can cut time is in that 90 day process. Then there is a 15 day process to do the analysis of the recommendations. That can also be cut some as well.
So, we are discussing that and have looked at, okay, 90 days. Do we really need 90 days? Can we cut that if all of the sudden we have got a lot of errata that is sitting out there and we need to move it to meet the deadline in 2001? So, we are in discussion and we have looked at where we can cut some time in that process.
DR. COHN: Let me ask a question about funding because I saw -- Maria, you had mentioned funding and I am a little bit confused here, only in the sense that in one sentence of your testimony you talk about the fact that the DSMO members have contributed to the development of the web site and you obviously see a web site here. You mentioned that the WEDI Foundation is funding the ongoing maintenance costs and in the next sentence you talk about there should be government funding to maintain, which is the WEDI Foundation is already doing and then also to improve it.
S, who does what, where or maybe you can explain to me what the need is here. I think there may be some legitimate government needs, but I am just wondering if this is really where the issue is.
MS. WARD: Okay. Just as background from a historical perspective, we have had this discussion with the Department ever since we were negotiation with the MOU, for a long, long time. So, this has been something that we have been discussing on an ongoing basis.
The funding that is coming from the WEDI Foundation, the maintenance costs that we pay to Washington Publishing to maintain over the web site isn't -- that is reevaluated on an annual basis. So, WEDI could at any point decide that they don't want to continue that funding to maintain the web site. If that happens, where does that funding come from?
Each of our respective organizations, HL7, NCPDP, X12, have said we can't fund this thing as well. We have already put up $5,000 each out of our own money to build it. We are not going to be able to maintain it on an ongoing basis as well.
So, there is a need for just basic maintenance cost to the web maintainer. There is also the opportunity to make the web site, I think, a lot more robust but that costs and we don't have the money to be able to do that. So, what we have from our developer is a functional, fairly basic web site and what we are told is that it could have a whole lot more functionality if we had more money to contribute to the development of that. We are not in a position -- as individual organizations, we are not in a position to be able to offer that.
MS. WEIKER: Just to follow up, I do want to thank Steve Bass and Washington Publishing for putting up the site. They were working on it before they even had any money to actually pay for it. Steve has been very receptive to any changes, recommendations we have within a limit, as Maria said.
You know, he only had $30,000 to develop the site. So, Steve has done a good job. So, I don't want that impression to go out.
DR. COHN: Okay. Well, maybe I should make a comment here. First of all, let me comment publicly that I am actually a member of the DSMO. I am on the National Uniform Claims Committee representing the American Association of Health Plans. So, I am not completely unfamiliar with the process you are describing.
Certainly, as I look at other issues, I have long observed that the issues of the web site is somewhat superfluous, that really the big issue is the people power related to dealing with what likely are to be lots of change requests initially. I am actually a bit surprised -- if I were asking for something, I would be asking for help with the people power part of things, as opposed to help with tweaking a web site. I guess I am surprised by this. Maybe you could explain this one to me.
MS. WARD: I think there might actually be a correlation between the two. As it has been explained to us, what a web site, a more robust web site might be able to do is enable the publisher, for example, of X12N, which is Washington Publishing, the publisher of those implementation guides to improve that process, the process of actually publishing the implementation guides.
So, to be able to get the information that they need and have a more streamlined automated way of actually creating and publishing the implementation guides was one of the advantages that was discussed with us. As members of the DSMO, we all recognize that the main benefit of that would, in fact, be to X12, not necessarily to all of the other organizations.
Frankly, we didn't get to a point where we really pursued that much farther because we weren't in a position to be able to have that -- the funding to be able to do that anyway. There was really, I think, in terms of publishing of the implementation guides and being able to gather more information and more effectively and in a more streamlined manner publish the implementation guides was one of the main benefits of being able to improve this web site.
In regard to the, quote, people power -- and I will speak from the SDO point of view, and it would be also applicable to the data content committees, is most if not all of those organizations are made up or represented of individual companies, organizations, those type of things. Our employers, because of a business reason, business need, allow us to participate and to these type of functions.
Yes, there is a lot of volunteer time to actually participate in the organizations, as well as those of us that are participating on the steering committee and the DSMO. That does take a lot of our time, too. To fund a person or persons, I am not sure where you would put that money at because NCPDP, they have staff. HL7 has staff. Because these are ANSI-accredited consensus-building organizations, I mean, they are going to go there, review them, those type of things.
So, the volunteer effort by members and the people that actually are in the organizations and on the committees do volunteer a lot of their time. So, in regard to hiring staff or something like that, I am not sure where we would put that.
DR. COHN: Okay.
Kepa.
DR. ZUBELDIA: I understand that none of these issues have completed the process yet, but what are the facilities that you have to publish the resolution of the issues?
MS. WEIKER: On the web site in the one place where it has got the ten day calendar, there is the 90 day, which is once I say I am going to collaborate, then I have 90 days to do my business analysis. On the site there is the 90 day time frame. I would click on that and I would enter my business analysis of that request. And each organization that said I am going to collaborate would also do that as well.
Then at the end of the 90 days or if they all have entered them prior to the 90 days, as chair, I can close that down and then we look -- the collaborating organizations look to see if they have the same recommendation. If they do, then the final recommendation is posted onto the web site to where everybody can see that.
Then at the end of that 15 days, where everybody says, yes, we agree, then it is forwarded to the appropriate SDO to actually make the changes. Then that recommendation is posted and all of these have separate buttons, so to speak, on the web site, where the data would be entered and the requester can look at it, as well as anybody that goes out to the web site.
DR. COHN: And, Kepa, I was just going to comment that it appears, at least based on my review of the December batch that you provided us, most of those actually can't be resolved just by the DSMOs. I mean, they actually come away as recommendations that need to be forwarded to the Secretary or to the -- and NCVHS, which is correct also.
MS. WEIKER: Right. That is the final step of the actual process, is once the business analysis is done and the technical analysis or the technical design, so to speak, is actually completed, the DSMOs will forward any recommendations to this committee on, for example, the home infusion codes. If the DSMOs say we think they should be added, we would forward that recommendation to this committee.
DR. ZUBELDIA: They are posted in the work site in the general public area.
MS. WEIKER: Yes.
DR. ZUBELDIA: This gives two places to look for progress or questions and answers that have been resolved. One is the admin sim site. The other is the DSMO site. So, if you are going to have a link between the two, I would recommend that you have a link between the answers in both sites. So, you can easily go from one site to the other or have one collection point for all the answers, whether it be to a DSMO question or to admin sim question so people don't have to be bouncing back and forth between two sites.
DR. COHN: More questions, comments?
My understanding is that you are going to -- both of you, Margaret and Maria, are going to be here for the next panel. Is that correct?
MS. WEIKER: Yes.
DR. COHN: The reason I am asking is that it is -- you know, somebody could talk about process out of context and you will hypothesize that there is going to be a flood of requests coming down, many of which are going to be somewhat problematic.
Yet, we are sitting here looking at four or five requests that have come through the DSMO process. I think in the next panel we are going to be hearing about -- through a myriad of issues that seem to be coming up, many of which are not just technical changes to the guides.
So, I think as we begin to look at them, we are going to need to reflect a little bit about what the process needs to be, both from the DSMOs. Can you gear up to handle the process -- issue? We are also going to have to reflect at the NCVHS level about what sort of happens after you have thought about some of these issues and what we also need to do.
I think it would make it a little more helpful to have that discussion in the context of beginning to hear some issues that seem to be coming up. So, rather than pursuing that right now, I think it makes more sense to come back to it after we have listened sort of to the next panel and then reflect on what sort of a process needs to be put in specifically for this year, recognize that we have an opportunity between now and October.
After that, hopefully, things will become a little more orderly, but things are going to be, I think, somewhat disorderly over the next seven or eight months.
Any comments before we -- everybody is sort of nodding their head on that one.
MS. WARD: There is something that -- very much related to what you are talking about that I think it is important for people to understand and that is as we talk about the DSMO process, this web site and our ability to as a steering committee control sort of the process to the world, you know, their input and how they enter their change requests, the real work is being done by the individual organizations, by those who opt into these things.
So, I would suggest that it is the organizations, it is X12, it is HL7, NCPDP, the data content committees, that need to be certain that they are prepared as organizations to handle whatever might be coming down. It is not so much -- this web site can handle whatever, you know, the world is ready to give to it. All that really is is a filter. What happens is the downstream effect of that is can X12 handle it, can HL7 handle it, can NCPDP handle it.
So, I think a more important question is what are the processes that are in place within those organizations to handle that?
DR. COHN: To respond to that, I actually agree and I guess my thought is is that at least my understanding of the MOU that you all signed was not about a web site or a piece of technology, but it was about agreement for all of the designated standards maintenance organizations to work together to make what were legitimate business and national needs.
So, in some ways I am looking at you not as a web site, but as representatives actually of that process. I do agree with what you are saying, but we can't put our fingers elsewhere necessarily.
MS. WARD: No, and I am not suggesting that we do. I am just suggesting that at a certain point when we all go off and do our individual like in the 90 day analysis period, what is going to be important is that there is an infrastructure in place in each of those respective organizations to do that, to be effective in doing it and to do it in a timely manner.
We have expended a tremendous amount of effort within HL7 to make sure that that will happen. So, I have absolutely no doubt that we are going to have, you know, a good time in HL7 dealing with this, but I would say that the rest of the organizations need to be as confident in that.
MS. WEIKER: Well, Maria, since you have thrown down that gauntlet, NCPDP is ready. Bring it on.
MS. WARD: All right.
DR. ZUBELDIA: Following up on Dr. Cohn's question, if the idea was to meet together and resolve these issues, is that happening or we talking about each organization going off on their own and not talking to each other and resolving the issues through this virtual median?
MS. WEIKER: In the MOU, there is the collaboration, organizations. It is not a must. It is a shall appoint liaisons to actually do any kind of joint development if more than one group decides to collaborate on them.
If you look at the first batch of change requests, you see where X12N has opted in appropriately and the NUBC in regard to a lot of the institutional changes. The NUBC tends to go to the X12N meetings. X12N is represented on the NUBC. So, there will be those cross discussions at those organizations. But ultimately once the -- and they still may disagree, but once those are entered, then we will meet and we will see if we can't iron out a true resolution.
We are still in the first 90 day period of the first batch and at the next hearing, we will be much farther along in the process. So, we will have a better idea, you know, are we all playing together nicely and collaborating and getting this stuff done as it needs to be done.
DR. COHN: Other comments, questions? I think we will pursue it -- this will be sort of a theme that we will be pursuing through the meeting, I think, as we reflect on issues that implementers are beginning to identify, which is obviously the point of the next panel.
Now, we are running a couple of minutes early, which is wonderful; one of the first times it has ever happened in one of our hearings. Of course, we did start at 8:30 as many of you will notice, which is actually 5:30 California time.
It is actually now about 20 minutes to 10:00. Why don't we take about a 15 minute break and reconvene at five minutes to 10:00 and that will give us an extra couple of minutes for the actual panel.
[Brief recess.]
DR. COHN: First of all, I think, before we start into this panel, we have had another member of the subcommittee who has come in. Clem, would you like to introduce yourself?
DR. MC DONALD: Clem McDonald from Regenstrief Institute and Indiana University.
DR. COHN: Okay. Thank you.
In our briefing in our first discussion we sort of were beginning to talk about the issues. Obviously, this panel is sort of bringing it down a couple of notches into like what are the early issues that we are beginning to identify as various groups are out looking at what is going on and then, hopefully, after we have had a chance to hear some of these issues, we will begin to reflect back at the processes that we need to make sure that these things get appropriately resolved in the right time frame.
With that, I think, as I look at this, the title of this panel is "Data Issues and Other Implementation Issues," which I think is an appropriate name for this panel. Our first presenter is Mary Emerson from HCFA. Is that correct? Do you want to lead off? Okay.
MS. EMERSON: My name is Mary Emerson and I am from the Health Care Financing Administration.
I guess the thing I would like to say about my presentation is that it is going to be one more kind of higher level presentation before we get down into the nitty-gritty of the actual data issues.
We began to hear shortly after we published the standards for electronic transactions regulation that there may be issues with some of the standards that we had adopted, that the Secretary had adopted. A group got together from the X12 workgroups to start looking at errata that were being reported in the implementation guides and people began to ask, well, if we find changes that may need to be made to the standards, how would those changes be made?
What I would like to do is to go through the parts of the chart that you have as a handout. The chart is entitled "Maintenance and Modification of the Standards." What it attempts to show is the processes that were laid out in the final rule that can be used for maintaining and modifying the standards and some of the constraints that apply to each of those kinds of changes that may be made in terms of the compliance dates and the frequency that changes can be made.
Before I start, I would just like to tell you what -- how the chart is laid out. There are four columns in the chart. The first one goes through the kinds of changes that might be made to the standards. The second one gives a reference in the final rule, where that type of change is described and where the constraints of that change are given.
The third column tells whether a regulation would be required in order to accomplish that kind of change and it tells some of the constraints in terms of the compliance dates and the frequency of making that kind of change. Then the fourth column tells what processes would be used. So, some of the questions that came up in the earlier panel on the designated standards maintenance organization, I hope, will be answered as we go through this chart.
The final rule for electronic standards for electronic transactions made a distinction between the terms "maintenance" and "modification" and laid out different ways that maintenance would be handled as opposed to modification. Basically, the difference in definition, you could think of maintenance as being a minor change that does not result in a substantive change to that standard.
Modification is a more major change that has to be adopted by the Secretary through a rulemaking process. The first two items in the chart talk about maintenance of the transaction standards and then the code set standards. Just to give an example of what might be included in maintenance, that is, these non-substantive changes, an example might be typographical errors, technical corrections that don't result in a substantive change.
Those kinds of changes can be made by the standard developing organizations that maintain those standards. There is no need for a federal regulatory process, publication of a proposed or final rule in order to accomplish those kinds of changes.
Similarly for the code sets, maintenance might be adding a new code to an existing code set or marking certain codes as deleted or no longer used after a certain date, something along those lines, and that kind of maintenance is normally done by the code set maintaining organizations. There is no federal regulatory process needed to have that go on.
Now, the change comes when you get to the modification of either the transactions or the code sets. Modification of the transactions is shown in the third item on the chart. Modifications would be -- would include such things as adding new data elements to a transaction or changing the number of repeats of a loop of a transaction, changing which kinds of code sets are allowed for a data element in a transaction. These kinds of changes would normally result in a new version of an implementation guide for the transaction.
Those kinds of changes would be modifications and they would have to go through a regulatory process. Now, I want to tell you what the constraints are for the modifications and this will hold through as I go through talking about a few other kinds of modifications.
For a modification, the compliance date can be no earlier than 180 days after the effective date of the final rule where this modification is adopted. So, in other words, you have at least six months that people must have in order to implement a modification.
There is no outer limit to the amount of time allowed for implementation of a modification. The Secretary may consider the extent of a change and the time needed to comply when the Secretary sets that compliance date. A compliance date would be set in the regulation but we aren't constrained as to how far out that date can be.
Modifications can be done on an annual basis. And as you have heard from the discussion in the first panel, there is a thought that the designated standard maintenance organization process might be done on an annual basis. This could be done with the constraints that we have in the final rule.
The process that was laid out in the final rule for having any modification made was the designated standards maintenance organization process. Just to sort of recap it in a nutshell, that process includes the process that the standard developing organizations go through, normally, the designated standards maintenance organizations would make recommendations to NCVHS. NCVHS might make recommendations to the Secretary and then the Secretary could publish a regulation that would adopt the standard, the modification to the standard. That is the way that full process would work.
The next kind of modification would be modification to a code set standard that we had adopted. An example here would be -- since we are going to have the panel this afternoon on national drug codes, I picked this example. Right now the standard for reporting any drugs is the national drug code. If the Secretary were to modify that by saying that HCPCS drug codes would be used on non-retail pharmacy transactions, that would require a modification and it would be a modification to what we had already adopted for reporting drugs.
Again, the same constraints in terms of compliance dates and the same process would be used as for a transaction modification.
The fifth item on the chart is modifications within the first year because there are some special situations in which the Secretary may adopt a modification within the first year after the standard had been adopted.
Modifications within the first year have to meet a pretty high test. They have to be necessary in order to permit compliance with the standard. In other words, if a modification is going to be adopted by the Secretary within the first year, it can't just be because there was a mistake. It has to be a mistake that would prevent compliance with the transactions or with the standards.
This is the only situation where a modification may be made within that first year. Again, the same process would -- as far as the way that the standards for electronic transactions laid out the process, it did not make a distinction in terms of the processes that would be used for modifications within the first year, compared to other modifications.
So, the designated standard maintenance organization process would be used for modifications within the first year.
The sixth item on the chart is adoption of a new standard. This would be a situation where we had not already adopted a standard, such as we do not now have an adopted standard for the first report of injury. If we were to adopt a transaction standard for that, that would fall in this No. 6 category, as would adoption of new medical code sets, where we hadn't previously adopted a code set to handle that class of items.
The situation for an adoption of a new standard is different from a modification. In the case of adoption of a new standard, the compliance date for all entities, all covered entities, except for small health plans is 24 months after the effective date of the standard; no later than 24 months, I should say, after the effective date of the standard, and for small health plans, no later than 36 months. So, the situation here is a little bit different.
Here we do have an outer limit of what the compliance date can be; whereas, on the modifications, there was no outer limit of what the compliance date could be. Again, for adoption of new standards, the designated standard maintenance organization process would be used.
That really concludes the kinds of regulatory changes that might be made to the standards. In other words, we have the two kinds of modifications, the code set, the transaction. We have modifications within the first year and then we have adoption of new standards. But there were two other kinds of activities that people have asked questions about.
The first of those is Item No. 8 on the chart and that is the exception process that would permit testing a modification to a standard. That process was laid out in the final rule and basically the process is that people who want to test a modification and make a request to the Secretary of HHS, the Secretary may consult with the designated standard maintenance organizations in determining whether to agree to that request and then the Secretary may grant an exception period for up to three years.
At the end of that three year period, upon request, the Secretary could grant an extension to that exception period.
The last item on the chart is promotion of best practices, work arounds and so forth and, again, this would not require any sort of regulatory process. This would probably be an industry process and one example of such a process is the one that has been undertaken by the WEDI/SNIP groups, trying to find work arounds for some of the difficulties with the standards that have been adopted.
I would like to just make a few points in the bullet items on the end of the chart. These are things that have come up in conversations about the modification process. The first is that the type of regulatory process that HHS would be required to use would depend on the significance and the impact of the change that is being made.
In some cases, this might be a notice of proposed rulemaking and a full comment period and a final rule. In other cases, there are more expedited processes that could be used, but they depend upon the significance of the change that is being proposed.
Second, since we know that people are going to be talking about getting relief from some of these standards that have been adopted, in order for a modification of a standard that was adopted on August 17th of 2000, to take place before the compliance date for that standard that we adopted, the effective date of that modification has to be around April of 2002, in order to allow that 180 day compliance period before August of -- I am sorry, I have said August. I meant October of 2002.
The third bullet addresses the errata process that the Accredited Standards Committee, X12N Workgroup, authoring groups, have been going through, they have identified errata in the Version 4010 Implementation Guides and some of those errata may require changes in order to permit compliance with the standard.
So, they may fall within that -- meet that test where modifications would be appropriate in the first year. The workgroups are right now talking about how they might want to handle these errata. One possibility that has been proposed is to publish corrections to the errata as an addendum to the 4010 Implementation Guides.
Another idea that has been put forward is to republish the 4010 Implementation Guides, but in any event the adoption of that correction by the Secretary of HHS in order to make it part of the standard would have to follow Line No. 5 on the chart if it is done within the first year. If it is not done within the first year, then it would fall probably in Item -- I guess it would be 4 on the chart or 3, depending on whether it had to do with the code set or a transaction standard itself.
PARTICIPANT: [Comment off microphone.]
MS. EMERSON: It would probably be in Item 3 since it is transaction workgroups that I am talking about.
Okay. And a couple of other points about the designated standard maintenance organization process, the final rule did describe that process as being used for modifications. As we have already heard, there is some question about whether we can get through that process quickly enough if we want to use it to modify the standards within the first year.
Maybe some sort of expedited process will be necessary. Margaret alluded to that earlier, that that is one thing that is being discussed.
The final rule also said that the designated standard maintenance organization process would be used for adoption of additional code sets. Some of the feedback from a few of the members of the designated standard maintenance organizations was that their expertise, the reason they are members of that group, is that their expertise lies in the transactions that have been adopted.
They may be if they are trying to decide whether to recommend an additional code set, they may be called upon to make a judgment whether a proposed new code set overlaps with one that is already a standard or whether the codes that are in the new code set might more properly be included in a code set that is already a standard.
We need to think about whether or maybe they can give us feedback on whether they feel they are the proper body to make those kinds of decisions. As things stand now, the final rule does say that the designated standard maintenance organizations, that process would be used for adoption of additional code sets.
The final bullet just is meant to show some of the complexity when you get into the question of adopting a new code set that has to be included in the transaction. It could be that the code set will be recommended to be adopted and that code set is not even in the X12 standard at this time.
In that case, the X12 standard would need to be changed to include that code set. The implementation guide then might need to be changed to make that -- to include that code set or to make it used in the transaction. Then the code set itself would need to be adopted by the Secretary. You get into a bit of a chicken and egg situation there where the code set isn't yet adopted. So, how can we put it into the transaction or. you know, if we put it into the transaction and it is not adopted and people start using it, what happens then?
So, the complexity of timing or some of those code set adoption questions is something that we will have to deal with in the future.
I want to thank the subcommittee for allowing me to testify. And that concludes my testimony this morning.
DR. COHN: Mary, thank you for the very informative discussion.
Dave Moertel.
MR. MOERTEL: I just want to help the group with the notion of whether or not there will be a flood of comment on the DSMO site. I can guarantee the flood has begun. I started it yesterday myself. It will have a lot of activity for the DSMO group to work with over the coming months.
My name is Dave Moertel. I am the manager of electronic commerce for the Mayo Foundation. It is my pleasure to appear today on behalf of the Mayo Foundation and a number of other health care provider organizations before the Subcommittee on Standards and Security of the national Committee on Vital and Health Statistics.
I would like to thank you for the opportunity to testify. My statements will respond to the questions that have been proposed by this panel in the questions about reporting of industry's early experience with HIPAA implementation.
The first question has to do with have you or your organization members performed a gap analysis to compare the data you already have available electronically with the data that are contained in the HIPAA transactions. If so, what gaps are there between the data elements you collected electronically and what is within the HIPAA X12 837 Claims/Encounter Transaction Implementation Guide?
I need to clarify that question because I think the question really means the 837 version 4010. If we were talking about the 3051 transaction, my answers would be considerably different.
Mayo created a HIPAA compliance team that focused on reviewing the HIPAA implementation guides. The team also created a gap analysis comparing the data available electronically with data contained in the HIPAA transactions. They found a large number of new data requirements and have determined that the infrastructure changes required to be in compliance are extensive.
Based on this analysis, we convened a meeting of provider organizations, provider associations and representatives from HCFA to review the list of data elements. In addition to the Mayo Foundation, we had representatives from Park Nicollet Health Service, Health Alliance, Allina Health Systems, MGMA, Carle Clinic, Superior Consultants, the University of Kansas Medical Center, the Cleveland Clinic Foundation, Ascension Health, Fairview, Ochsner Clinic, the University of Alabama Health Services Foundation, Cape Girardeau Surgical Clinic and, in addition, a number of associations, the American Medical Association, the American Hospital Association, the American Dental Association, the National Uniform Claim Committee and the Health Care Financing Administration.
The reason I list these is to give an indication that we do have a broadly representative group for the provider industry.
The group evaluated the Mayo analysis and determined that the gaps identified were common issues for the provider industry. The tables of these issues are attached in Appendices A and B and after reviewing the issues we went through an issue prioritization process and found that 29 of the issues that we identified in the Professional Guide and 15 of the issues from the Institutional Guide were considered Priority 1 or high priority issues.
All of these issues are attached to this testimony and instead of discussing each of the more than 40 issues individually at this meting, I would like the opportunity to work with somebody from the subcommittee at another time in order to explain all of the issues and the recommendations in detail.
The second question has to do with is this gap a barrier for you to implement the HIPAA 837 standard? If so, what are your plans to resolve the barrier?
The high priority items on our list are issues that create barriers to the implementation of this standard. Even low priority issues when viewed as a whole create a barrier.
In our provider group discussions, a common question was whether or not the new required data elements reflect universal business needs for the healthcare industry or are the requirements expressed by a single payer or state agency. A major issue that arises from the universal transaction philosophy is that the burden then falls on the provider for reporting all the requirements in claim transactions. A given provider is now obligated to provide required elements on all claims to all payers, even though none of the business partners of that provider may need that element.
Those payers then, not needing that data element, will need to process the claim and maintain the data element so they can either pass it on on remittance advice or pass it on to a secondary payer as part of the COB process. So, our provider group believes that if the elements in question are not currently necessary for billing services, the elements should not be required for HIPAA implementation.
It appears that some of these data elements do not reflect a universal business need or they are requirements expressed by a single payer or state agency. The 837 Implementation Guides were developed for the purpose of reporting claims services from providers to payers. If the inclusion of some of these elements was to fill other needs, as an example, the state public health reporting, they should not be required elements to be reported on the claims transaction.
In fact, our provider group supports the position that the 837 standard should be utilized as the transaction to report data for public health purposes. However, we believe that a separate implementation guide should be developed to fulfill those needs.
The group believes that in order for administrative simplification and the health data standards addressed by the Health Insurance Portability and Accountability Act to be successful, some of the data elements in question are going to require some compromise. Oftentimes there are other more widely accepted methods for capturing this same information. While the law provides a framework for administrative simplification, significant work still lies ahead for all those involved in these transactions; the modification of the standards and the implementation guides, the review processes needed to establish uniformity in the use of the standard transactions and overseeing and updating the process as needed.
As you may know, the electronic data interchange involves the exchange of information not only between parties and their computers, but also between business applications. When this communication is exchanged electronically, each party reformats its outbound message from its internal processing format into a standardized data format. This process is referred to as data translation and is performed for both inbound and outbound data.
For example, the trading partner that receives a standard formatted electronic message translates the incoming message into their own internal format before processing the message in its application system. By using a standardized message, including uniform data content, organizations can communicate effectively with each other.
As the implementation date of these standards moves closer, the implementation guides that have been developed for the transaction must be adopted consistently across the industry. Our group believes it is unreasonable to expect that every provider in the nation will be required to modify their systems and collect and report certain data elements in order to accommodate a single or small number of payers.
We found that in many cases it may be impossible to collect the required data element information. Furthermore, our analysis found that in some cases providers would have to make modifications to their systems to comply with the requirements of the new standards. In other cases, we believe that an industry review must be done in order to identify the percentage of the industry that requires certain data elements. If that percentage is low, then that requirement should be removed.
In addition, we found that there are other data elements that are required due to certain state law requirements. This means, again, that every provider in the country is required to report certain data elements, even if the state they live in or the payer doesn't require that element. This defies the purpose of HIPAA, which is to create a universal national standard.
These types of requirements need to be eliminated. With the establishment of the DSMO process, we believe that future requests to fulfill the requirements of an individual payer or provider will not be accepted. Our plan is to send all of our issues through the DSMO process for review. As a matter of fact, that has been initiated.
Our concern is that the DSMO process is set up to handle issues with new versions of the guides. We are seeking immediate relief from the Secretary this year. The cost of compliance with the current data element requirements will impose substantial financial risk to the healthcare industry.
If the DSMO process is utilized, healthcare participants will be required to make costly infrastructure changes to be in compliance with the data requirements indicated by the current implementation guides. As indicated in the law, the Secretary may adopt a modification at any time within the first year if the Secretary determines the modification is necessary to permit compliance with the standard.
The third question posed by this committee is what other implementation issues do you have with any of the other HIPAA standard transactions and what are your plans to resolve these issues?
Now, many of the organizations that we are working with are following the same path that is outlined by the WEDI/SNIP process. Therefore, our focus has been on the claims transaction, one of the first in that schedule. However, we intend to analyze all of the other implementation guides and certain code sets in the order in which they were identified by the WEDI/SNIP implementation schedule.
For example, the remittance transaction may not pose a large risk to the provider community because the onus there seems to be on the payer when it comes to transmitting data content. However, the group has discussed some problems with the claim adjustment reason codes and CAS rejection codes.
The claim adjustment and service adjustment segments provide the reasons, amounts and quantities of any adjustment that the payer made either to the original submitted charge or to units related to the claim or service. The standardized list of claim adjustment codes, as examples, the OA, the CO, CR, PI and PR, are to provide explanations of liability of the financial adjustment to the claim or service line.
As a provider, use of OA or other adjustments, makes it difficult to ascertain the liability of the provider or the patient and necessitates a follow-up telephone call to the payer. The use of a PI, payer initiated reductions, can also be difficult for providers as it implies to our patients that the provider should be taking a reduction to the payment, even though the provider is not legally obligated to do so under a contract or government regulations. Although the implementation guide does recommend that payers should avoid the OA group, it does not prohibit payers from using that group code.
Similarly, the CAS rejection codes, No. 16 and 125, are the most oblique for the providers and will automatically require a follow-up phone call if the proprietary information is not transmitted by the payer and thereby understood by the provider.
The group also has discussed the provider taxonomy codes and we believe that there will be problems for providers if required to report them to the payers. Providers and probably payers will face costly infrastructure changes if they use the provider taxonomy codes because the list is extremely granular and out of date. Payers are asking providers to report information, example, provider specialty, that should already be in the payers system. This is an adjudication problem with the payers system. There are other ways to identify specialty instead of putting the burden on the providers to provide it on the claim.
For example, a physician could be board certified in several specialties or subspecialties. This is certainly true for the Mayo environment. It becomes a big problem for the billing department because they are responsible for submitting the claims. They may not know which specialty to submit for services. Provider specialty is not currently reported and should not be a required HIPAA data element for providers to report in the future.
Another example, the group determined that the NDC codes will present major problems for both professional and institutional claims reporting. Not only is the 11 digit length of the NDC code an issue, but the mapping of the J codes to the NDC codes would be a manual process in the clinic setting. Training, of course, would be necessary for clinic personnel to identify NDC codes for each drug supplied to each patient and this responsibility may go beyond the scope of the personnel's licensure or agreement. In addition, how would drug mixes or cocktails be handled? Would separate NDC codes be required for each drug or only the drug be identified or only one drug be identified?
When mixes and cocktails are used, would the clinic or hospital then be considered a manufacturer? Would they need their own manufacturing code? There are a number of questions that have come up and I have attached some of our questions as Appendix C in your document. The provider group has concluded that the NDC codes should not be used for professional or institutional HIPAA claim reporting purposes.
The fourth question has to do with are there other implementation issues, i.e., the X12 formatting or structure, HIPAA education, industry and government communication? If so, what are they and what are your plans to resolve them?
The provider community faces a significant education issue. The issues that we have outlined are known to the members of our HIPAA provider group, but what about the thousands of providers and vendors, who don't know about the gaps that we have identified and the extensive infrastructure and practice changes that will be required to accommodate them? For many of the providers who do become aware of these issues, they may not have the financial resources to make the required system changes necessary for compliance.
We view the X12 formatting and structure as a simple mapping issue. The bigger issue has to do with having the data available. the gaps that we identified will require significant changes throughout provider systems. This will have to begin with the physician, nurse or paramedical staff, who is charting the information and would need to be carried all the through to the patient accounting system.
On behalf of the Mayo Foundation and the other participants in our group, I would like to emphasize our shared commitment to advancing standardization and administrative simplification . However, there are several issues that we feel need to be addressed. The following points summarize my statement and recommendations for achieving the goals intended by administrative simplification.
The group evaluated the Mayo analysis and determined that gaps identified were common issues for the industry. A common question that was discussed was whether or not the new data elements that are required reflect a universal business need for the healthcare industry or are the requirements expressed by a single payer. The group believes that most of the elements that we are concerned about do not reflect a universal business need.
Second, the HIPAA 837 Implementation Guides were developed for the purpose of reporting claims services from providers to payers. If the inclusion of some of these elements was to fulfill other needs, they should not be required data elements for the claim. In fact, our provider group supports the position that the 837 standard should be utilized as the transaction to report data for public health purposes. However, we believe that a separate implementation guide should be developed to fulfill those needs.
Third, in some cases, providers would have to make modifications to their systems to comply with the requirements of the new standards. In other cases, we believe that an industry review should be done to identify the percentage of the industry that requires certain data elements. If that percentage is low, based on the number of payers or the volume of claims, then the requirements should be removed.
There are some data elements that are required due to certain state laws. This means that every provider in the country is required to report a certain data element, even if only one state or payer requires that data. These types of requirements need to be eliminated. This goes against everything that the HIPAA legislation is trying to create, i.e., a universal national standard.
We are seeking immediate relief from the Secretary this year. The cost of compliance with the current data elements will impose substantial financial risk to the healthcare industry. Providers and probably payers will face costly infrastructure changes if they use the Provider Taxonomy Codes because the list is extremely granular and out of date. Payers are asking providers to report information that should already be in their system . Provider specialty is not currently reported and should not be a required HIPAA data element for providers to report in the future.
It was determined that the NDC codes will present major problems for both professional and institutional reporting. The provider group has concluded that the NDC codes should not be used for the professional and institutional HIPAA claims reporting purposes.
Our plan is to send all of these issues through the DSMO process for review, but our concern is that the DSMO process is set up issues with new versions of the guide. We are seeking immediate relief from the Secretary this year. As indicated in the law, the Secretary may adopt a modification any time within the first year if the Secretary determines the modification is necessary to permit compliance with the standard.
All of these issues are attached to the testimony. Instead of discussing these issues here, I would like the opportunity to work with somebody from this subcommittee at another time in order to explain all the issues and recommendations in detail.
Again, I would like to thank you for the opportunity to present these views of the provider group and I would be pleased to respond to any of the questions that you might have.
DR. COHN: Thank you. And we will, obviously, deal with questions and issues at the end of everyone's testimony. Obviously, thank you for the multiple pages of issues you have identified.
Don Bechtel, next.
MR. BECHTEL: Members of the committee and Dr. Cohn, I am Don Bechtel. I am an advisory analyst for HDX, a wholly owned subsidiary of Siemens Health Corporation, where I am currently focused on strategic issues related to administrative simplification. In addition to my responsibilities with HDX, I am also a co-chair of the Transactions Workgroup for WEDI/SNIP. It is in that capacity that I will be presenting to you today.
On behalf of the WEDI/SNIP co-chairs, Christine Staloco(?), Rob Tennant(?), Larry Watkins, I would like to thank you for this opportunity to testify today on issues related to our analysis and early implementation experiences with using the HIPAA X12 Transaction Standards.
WEDI/SNIP began its work to evaluate the transactions in June of 2000, starting with a number of issues that were brought forward by the first WEDI/SNIP conference by the WEDI members and several AFEHCT white papers. During this meeting, we divided our work effort into five subgroups, which were described to you by Lee Barrett during his testimony in November. Today I would like to share with you some of the issues that we have begun to identify.
First, I would like to point out that the goal of SNIP is to resolve implementation issues related to the implementation requirements set forth by the law, regulations and implementation guides. We are not attempting to discuss or recommend changes to HIPAA regulations. Rather, we will to identify work around solutions or best practices that might mitigate a problem and allow implementation to proceed.
That being said, we are hearing issues that may require changes to the regulation, which are being noted and passed to the appropriate DSMO or the Department of Health and Human Services or to the WEDI HIPAA Success Task Group. The first sub-workgroup that I will report on is the sequencing sub-workgroup. One of the objectives of the WEDI/SNIP is to promote a deployment schedule for an orderly sequenced implementation of the transactions.
Our concern is that without such a national plan, each covered entity will work to their own schedule or local regional schedule that does not align with neighboring regions or states. This approach would put most entities in a position of having to be prepared to implement all the transactions at the same time, but not with all trading partners because each trading partner would potentially take a different approach.
From this, we would begin to experience implementation difficulties resulting from a non-orderly and confusing implementation schedule that could be dictated by some organizations directed differently by each trading partner. This scenario would put many organizations at risk of not having enough resources to focus on the implementation task that will be created.
They know that some transactions will need more time to develop, while others will need more time to implement. Therefore, we are trying to find a sequence approach that addresses these concerns and is logical and effective for more organizations. We also considered return on investment, trying to put those transactions that offer the most return on investment up front to help fund the development of the other transactions.
We have recently submitted a sequencing proposal for the industry via our web site and e-mail announcements asking organizations to review the proposal and comment on their ability to follow it. We also asked that other organizations -- I am sorry -- we also asked for other information, such as expect the cost to implement expected resource commitments, implementation strategies, implementation barriers that we might be able to address within WEDI/SNIP to keep the implementation process moving forward.
The results of our survey are still being collected and evaluated, but I would like to review with you some of the very clear and distinct and consistent messages that we have received so far. The three most critical implementation barriers are cost, limited time and elimination of local codes. Other issues that ranked very high were NDC codes and new transaction content.
In terms of sequencing, our fears that many organizations may have different plans proved well-founded. Of those organizations responding, 15 percent said they would follow the WEDI/SNIP proposal, while 40 percent said they were still evaluating their plans and couldn't comment on the sequence and the remaining 45 percent offered different alternatives, of which very few matched anyone else.
From this, we can only hope that the WEDI/SNIP can convince the 40 percent that are undecided to follow our implementation plans. As we also evaluate the comments, we will try to determine if there is a way that we can modify our proposal to make it more appealing to the majority of organizations.
Many organizations are still doing their gap analysis and indicated that their implementation plans were not firm and that it was possible that remarks or comments that they gave to us would change. Many other respondents indicated that they couldn't give us information at all because they were just too early in the process.
There is concern that the staggered release of final rules will impact the work already completed for HIPAA compliance, forcing them to go back to their applications and make additional changes, thus increasing the cost of stability of their enhancements. Some organizations felt that they would rather wait until all the rules were final and published before they began to make these enhancements.
A number of organizations commented that the time to complete the development, testing and implementation was too short as they felt the scope and complexity of the changes were very large and they were concerned for us to complete this work, it could introduce potential problems in the health community related to providing good and timely service for the transactions being processed.
A number of organizations reported that they need to acquire new systems to implement the HIPAA transactions and associated changes for the code sets and data content. We felt that the time to go through the acquisition and implementation process would take more time than is available to them.
There were many other issues identified and many of them are not issues that can be addressed by WEDI/SNIP. These are being compiled into a report that will be given to the WEDI HIPAA Success Task Group, which will review and consider these and provide input to the Department of Health and Human Services and this committee.
Work being done by the Data Review Sub-Workgroup is focused mostly on transaction inconsistencies and ambiguities To date this workgroup has not identified many issues. We believe that there are two primary reasons for this. First, we are very early in the implementation process and many of the organizations in our industry and still doing a gap analysis, as was shown in our survey.
This can be deduced -- and WEDI/SNIP relies on volunteers to come forward with issues they have uncovered during their own analysis. They are not sponsoring an effort to do this analysis as a workgroup. Rather, we are trying to bring forward industry issues from the industry and try to work through them.
A second reason a few issues have been brought forward in our opinion is that those who are doing this analysis are the same people who are deeply involved in X12. Many of the implementation problems that are being found are within the implementation guides and are currently being addressed by X12N via their errata process. These issues are not coming to WEDI/SNIP for a work around or best practice solution. Rather, they are seeking fixes to the implementation guides.
Those issues that are not fixed, I believe, will eventually find their way to this workgroup.
Following are some of the issues that have been identified by the Data Review Sub-Workgroup. The first is the X12 837 Claim Standard that is well-known, I suppose, at this point. It does not crosswalk well to the UB92 and the NSF formats. The issues are related to details, like data links and new identifiers. We are finding that many organizations will need to significantly modify their systems to collect and handle mid year requirements.
For example, currently the industry uses one facility code where place of service is assigned by a health plan. Under HIPAA, the health plan is required to support now four identifiers, one for the health plan, the provider, the patient as assigned by the provider, and a claim.
We are beginning to identify transaction inconsistencies and the first issue that has been identified to us is with the 837 dental claim, where this has been designed to work for predetermination of benefits. For other lines of health care business, this is being done by way of the X12 270271 healthcare eligibility transaction or by the X12 278 authorization and referral transaction.
They would use the referral transaction or the authorization transaction if they were looking for authorizations. This becomes confusing to the implementers since it is unclear which transactions are to be used and, further, could lead to issues of inconsistencies between other transactions as the maintenance results in two or more transactions trying to support the same functions.
This kind of issue can be resolved with a best practice recommendation and suggestions to the DSMO X12N to correct the problem in future versions. We have identified problems with the X12 278 authorization referral transaction that could be a showstopper for use with Medicaid programs. In this situation, a transaction does not support clinical information that is required by many state Medicaid programs to provide authorization for services.
This will probably prevent those Medicaid programs from implementing the 278 transaction and force them to continue to use existing methods of processing. There appears to be no remedy to this problem without changing the actual transaction. This is not an implementation guide issue. It is a transaction limitation that must be corrected.
Such a change will likely take at least a year to move through the X12 process. Data gap analysis is also being done by AFEHCT in the administrative simplification print image research effort or ASPIRE. I believe you will be hearing testimony very shortly from Catherine on that subject.
In the Translations Sub-Workgroup, we are also looking at a number of issues that are related to problems being able to translate data elements from one code set to another. This becomes an issue when trying to continue to do processing as you do today, but use the new transactions when you use the old transactions to move into your new processing environment. So, you need to translate back and forth.
Where we begin to see issues with these kinds of items or with the NDC codes, which do not crosswalk well with the HCPCS J Codes, while it is possible to translate from the NDC code to the J Code, it is not possible from the J Code to the NDC because there are many possible NDC that could be described by one J Code.
This is sometimes referred to as a many to one translation problem. This particular issue becomes a problem for those organizations that cannot convert their systems internally to support the NDC codes in place of the J Codes. Some organizations are considering the notion of converting the NDC code to the J Code equivalence so they can perform adjudication processing.
However, when they must report back on the remittance transaction information about a drug on the claim, it will not be possible to convert the J Code back to the NDC. The translation engines will not be able to do this translation.
An alternative to this is to have the -- to the J Code to the NDC translation issues, to store the inbound transaction and reassociate the NDC code to the J Code, based on some location reference. However, there is skepticism that this new association can always be done due to the complexities of these transactions.
Mapping taxonomy codes to the HCFA specialty codes causes a similar problem. The new taxonomy code list is much more granular than the HCFA codes used in the specialty codes and if the translations were required for interim processing during the implementation transition phase to HIPAA, there would be similar results to what we see in the NDC codes.
One could translate from the taxonomy codes to the older specialties, but it would not be possible to translate back to the taxonomy codes. An important option to avoid these transitional problems is to implement such code sets at the end of the implementation phase. In other words, the X12 transactions would be implemented using the J Codes and the specialty codes that we have today, which are currently supported in the X12 transactions.
Then following the conversion efforts from the format and other data content, the new code sets would be implemented. The resistance to this solution is that it adds another step to the implementation process and, therefore, the development efforts and it also extends the time.
Testing: The Testing Sub-Workgroup is looking at ways to improve our implementation validation process. A major concern in the industry is centered on the fact that it takes a lot of time and testing to implement new transactions between trading partners. with this short window of time available to the industry to complete the development and the implementation activities of the nine transactions, multiplied by the number of trading partners, this becomes a time critical task.
WEDI/SNIP has concluded that the mandated time frames will not be met unless we can find a more efficient way to conduct these implementations. This may be a topic for another time. We are actually writing some white papers on this and I would be more than happy to share those white papers with this committee as well.
The business issues, a sub-workgroup, its No. 1 concern that WEDI/SNIP has identified is the interpretation of regulations. Although there needs to be a place to take interpretation issues for resolution, such a formal mechanism does not exist today. Many times we simply ask someone within HCFA or HHS, who is working within our work group for an answer. Official answers take more time.
We believe the number of issues that will begin to expand rapidly as organizations begin or complete their analysis of their requirements and determine the data gaps and their questions. Specific issues center around -- that we have today, center around roles of clearinghouses, coordination of benefits, permissible implementations of direct data entry solutions and others.
Code set deficiencies are another area that this Business Issues Workgroup is looking at. They have written a white paper of the data and code set compliance, which outlines these issues and I have included that in my electronic copy to you for your review. The issues that they look at are the NDC codes and the business impacts that they have on various -- on the covered entities under HIPAA, business impacts eliminating local and procedure codes, diagnosis modifiers and trading partners, specific codes, are also discussed in this document.
Other codes, which are not governed by the DSMOs may require mapping to enable payers to utilize them for processing purposes. This paper considers how these mappings might be developed into best practices for greater consistency across the industry. Examples of this are taxonomy and adjudication reason curves.
Another issue considered is version control, the data standards and the HIPAA implementation guides, how these would be managed. The implementation guide requires that a claim be filed with a medical code set structure in effect at the time services were rendered. Code sets are required to follow the standard in effect at the time the transaction was generated.
This kind of issue begins to lead to some inconsistencies. Another hot topic within the workgroup is the use of alternative sources of transaction data for the main business transactions, specifically for direct data entry devices and browser-based applications that might be operated by health plans and clearinghouses. This white paper is finding a number of issues related to data content, including explicit or derived data, stringent versus reasonable field length requirements. For example, the phone numbers within X12 require 80 characters while 20 characters in most cases would probably be more than adequate to report a phone number.
I also included an electronic copy of this white paper for your review. Another issue that is in front of the work group is batch versus real time with regard to the eligibility transaction where today none of these transactions are being performed in a real time environment by way of phone or voice response systems. But the implementation guides require that these transactions be supported in batch, which will create problems to those organizations trying to implement this as they will have to create new processing to meet the requirement.
Another issue raised concerns when an X12 835 transaction must be electronically sent. This is not made clear in the adopted implementation guide. For example, must a provider who is only receiving paper remittance advice today only take an electronic transaction under the HIPAA rules? We believe that paper remittances would still be appropriate, but WEDI/SNIP believes clarification, such as this needs to be made.
In closing, I would like to thank the committee for allowing us to present our remarks and we also believe that there is much more to be learned and that we are only at the beginning of this process and we look forward to working with you further.
Thank you.
DR. COHN: Okay. Don, thank you very much.
Catherine Schulten, you are the final presenter.
MS. SCHULTEN: One of the great things about going last is you just get to repeat what everyone else has just said.
My name is Catherine Schulten. I work for a company called NEON, New Era of Networks. I am the HIPAA product manager for that company. I am also here representing AFEHCT's ASPIRE project and I am also a co-chair for the Translation Sub-Workgroup under WEDI/SNIP, which is probably the reason why you are going to see a lot of the same information that seems to occur in everyone's presentation.
The AFEHCT ASPIRE project -- ASPIRE stands for the Administrative Simplification Print Image Research Effort -- the goal of this project was to identify data content gaps that exist between the traditional paper claim formats that are used today and the HIPAA-mandated 837 professional and institutional electronic claim formats.
When I was last here in November, I presented on the same topic. So, I don't want to go down too much into the same detail because you already have that presentation, but I can address questions with that. So, I am just going to hit the high points of that presentation.
The issue that was originally raised was does a HCFA 1500 paper claim form contain all the necessary and required data needed to create a HIPAA compliant Version 4010 837 professional claim. The attempt to resolve this concern is in a demonstration project between various project participants representing providers, payers and clearinghouses.
So, everyone has seen the HCFA 1500 claim forms. This is a picture of it. It contains a subset of data that is present in the 837 professional transaction. It contains some data that is not present on the 837 and it is a form that can be turned into an electronic print image so you can facilitate mapping from the paper claim format to the electronic claim format.
The same thing with the UB92. It is a print image form. It contains a subset of data that is present on the 837 institutional transaction. It also contains some data that is not present in the 837 institutional transaction. The question was can you go from one to the other?
So, the high points of the project to date have been these categories of gaps. There are gaps between mandatory data content. You have heard this four times now. Provider taxonomy code is a big one. It doesn't exist on the paper claim form. So, how do you facilitate the mapping to the electronic format?
Another one is payer responsibility sequence. Is this the primary payer, secondary payer, tertiary payer? That information is not explicitly stated on the HCFA 1500 claim form. So, how do you facilitate the mapping from the paper to the electronic?
Data specificity is another gap. The 837 makes very clear distinctions between bill to, pay to and rendering provider. The HCFA 1500 does not. So, how do you make that assumption? How do you go from one to the other?
There is also ambiguity within the data element crosswalks. You are going to hear it for the fourth time. The J code, NDC code, it is that one to many, many to one correlation, very difficult to achieve.
Then there is also the issue with nonstandard use of the paper claim format. The HCFA 1500 and UB92 paper claim formats have fields that are just blank. They are defined by the payer. Sometimes they are defined by the state as to what type of information goes in those fields. So, you have an issue there with what information happens to be residing on that paper claim form at that particular point in time.
The last time I was here I talked about some of the solutions or work arounds. Usually they are the same ones. If we had some very precise implementation guides and by this I mean not just the 837 implementation guides that would have very explicit instructions, but also if the HCFA 1500 and UB paper claim formats had very explicit instructions on how to complete those fields, that could help facilitate that mapping, that crosswalk.
Industry-wide accepted crosswalks would be very beneficial so that we all knew how to achieve this. Trading partner agreements can be helpful in overcoming some of these gaps. If you tell your trading partner that in Box 4, even though it is a user defined field, I am always going to put the CLIA(?) number in this field, then you know where to find it.
Data enrichment, this is either the ability to take the HFCA 1500 form or the UB form and insert data that is not already defined for that field, place a taxonomy code in some margin off to the side. There is nothing that would necessarily prevent a provider from doing that. So, you could enrich the data that is already on the paper claim format, as long as you explained in your mapping translation process where to find that data or you could send an accompanying file with your paper claim format that provides extra data to support that transaction.
Finally, the publication and acceptance of best practices, which is something that is being taken on by WEDI/SNIP, putting these types of best practices and white paper documentations together. Some other issues have come up and Don pointed this one out, was the inability to support full data field length or maximum number of data element occurrences is a road block.
The 837 implementation guide supports an 80 character alpha numeric field for a submitter's phone number, for example. The 837 institutional claim allows for 100 CLM claim segments per patient, not to exceed 5,000 for ST to SE. Each CLM can have as many as 999 service lines. Many payer adjudication systems are going to have to be revised to accept these maximum data sets. They are not set up for that today.
So, the other solution to this, that payers might be taking on, is they are going to hope that this doesn't really happen. That is the solution. Some payers are working under the expectation that not many incoming claims are going to contain this maximum data set. They are banking on the fact that phone numbers are going to come in and they are going to be a set length and they are not going to have 80 characters sitting in the phone number field.
They are hoping that 999 service lines don't come in a claim because right now they just don't have the back end systems to handle that. If that claim does come in, they are going to have to be handled on an exception basis, which means manual processing.
Other issues that payers are facing, the payer infrastructure in place today is set up to accommodate an expected number of incoming claims and a few other selected electronic transactions, such as maybe batch enrollments from a certain sponsor that they happen to do electronic enrollments with.
HIPAA has the potential to increase dramatically the number of incoming electronic transactions that the payer will need to accept. Payers will need to electronically accommodate HIPAA transactions that are today traditionally handled, either by fax, on the phone or mail, such as the eligibility request, the claims status request, eventually claim attachments.
So, the payer is going to be in an interesting position of having to handle electronically and manually these two feeds of information and they need to do it in a consistent manner. There is going to be an issue here now with the business redesign. Payers will need to develop an appropriate system infrastructure to handle the expected increase transaction demands. They are going to have to reengineer systems for high speed, high volume throughput.
Payers will also need to put into place processes to respond both to the traditional phone/fax requests from providers, as well as the HIPAA transactional requests. Like I said, they can't have a different policy and procedure for handling manual requests or paper requests, than they do with the electronic request.
Another issue is that payers will need to be able to archive all incoming 837 claims and then link the data submitted as is with the 835 payment response. This was an issue that has been brought up by a couple of other people here today.
Other issues for providers, this is, hopefully, the mandated standards. Now we will make it easier and more cost effective for the providers practice management system to accommodate the HIPAA transactions. Providers are going to be pushing their vendors to supply this new functionality.
However, I think that there is going to be an issue with lag time in system development and it is going to impact the compliance deadline for some providers. The other issue that I have been hearing a lot about is the be careful what you ask for, you just might get it. Traditionally practice management systems were developed to facilitate claims submission and the posting of the remittance. That was it.
These systems are not supportive of this new interactive environment that we are going to be entering into. So, providers might actually have to just replace entire existing systems because they can't respond or be able to use these new transactions that are going to be coming out under HIPAA.
Just like the payer, the provider is going to face many challenges in establishing a business design that takes advantage of the HIPAA transaction standards without overwhelming system upgrade costs or clearinghouse fees.
The last question that was asked that we should address today was other implementation issues. The largest one that I see facing the industry is education and awareness. Industry-wide education and consistent communication continues to be a problem. The payers and clearinghouses are not representative of the HIPAA knowledge base that exists in the healthcare industry today.
There is a big gap between the -- the payers are somewhat knowledgeable. Clearinghouses are knowledgeable. This room is knowledgeable, but when you get down to the provider community, especially in the small physician practice, they just don't even have any idea that this is on the horizon.
So, we have a huge gap when it comes to educating the provider community. You wanted some suggestions on a few possible solutions to overcoming that education gap. I have been talking to some people. There was a thought that maybe the creation of some sort of continuing education course offering that addresses HIPAA requirements that could be provided for the provider community, online course offerings and tests to provide accreditation could also be very useful.
Thank you very much.
DR. COHN: Catherine, thank you very much.
I actually want to start by thanking the panel for a very interesting set of presentations. Maybe I will start with a comment and a question or two.
I am sort of scratching my head a little bit only because I am somehow feeling that based on these four presenters that it is like the blind men touching the elephant and all feeling different parts of him. If there is a little bit of crossover here in the discussions -- I am not hearing a lot of intersection between all of the discussions, priorities and issues. Obviously, that concerns me a little bit.
I mean, I hear people complaining that there is -- information systems may not be quite ready but then I also hear people complaining that these people who should be developing the information systems, maybe they -- you know, if they work right now with the current 837 transactions, maybe they are not quite right or the X12. We are mostly hearing representatives from the government saying, well, gee, we have got until April of the year 2002 at the final moment to straighten things out.
Obviously, we have all sorts of independent pieces that, you know, unless we get them aligned, we are not going to have successful implementation. I don't know. Maybe, Mary, could you comment on that? I am sort of -- you know, I was listening to your comments and the structure and I am just sort of --
MS. EMERSON: -- October of 2002. If these standards were modified at that point and people then had to react to implement within six months, they probably couldn't do it unless they had known long before that what these modifications were going to be. So, I don't think we should really look upon April 2002 as the date to try to make all these changes. That is just my assessment of it.
DR. COHN: Thank you for making that comment.
Before moving to the other questions, do others have comments to my sort of observation here or does everybody feel you are well-aligned and we are all moving forward easily -- well here?
MR. MOERTEL: Just a quick response, Simon.
A number of these issues that I have described will be flowing through the normal process and I think they will be much more alignment on the issues as these come forward. One of the interesting issues that I have faced with our gap analysis is that you will notice if you go through my list of issues, that they are not issues with the transactions. They are coding issues. They are issues that are going to impact the medical practice all the way back to the provider in some cases, capturing a baby's birth weight. We don't do that. So, now we have to capture a baby's birth weight. Who is going to do that? The doctor and the nurse.
So, what has happened is I am the manager of electronic commerce and I have been very focused on the HIPAA transactions and I can map a transaction. I can get that information out the door. No problem. Getting the data to process, getting the data to map is my problem and the problem facing my institution.
So, as we implement these new transactions with new requirements, we are going to be facing a whole new community in the provider group area that haven't looked at these issues before. This hasn't been their focus. They are coders. They are healthcare practitioners. They haven't been looking at what is happening with the electronic communications and transactions.
That has been my business. Now, my business becomes their business and until these regulations have come out, we haven't been able to activate those resources. Now that those rules are finalized and they are seeing that, yes, this is reality and we have got to face reality, the wake-up call is there. I have tried to engage other providers in the healthcare community before and the interest just wasn't there until the rules were finalized. Now that they are interested, they are finding out that there is going to be some significant changes.
So, I think the voice of the provider community, the voice of the payer community are going to start hitting groups like WEDI/SNIP, are going to be hitting on groups like the ASPIRE team and all of us are going to come together and try and work together to resolve these issues.
I indicated that now that we had put together our gap analysis and finalized it for our presentation today, that I have already introduced these topics to the DSMO site. There is going to be sort of a rude awakening when they look at the DSMO site today versus where it was a couple of days ago because now there are more issues out there than were there in the previous couple of months.
Those issues are also going to go to WEDI/SNIP. They are also going to go to the ASPIRE group. We were trying to be very focused and look at this from a provider's point of view first. Now we are going to let everybody in the industry know what our issues are, but we wanted to make sure we were speaking as a provider community versus single voices.
DR. COHN: Clem.
DR. MC DONALD: I actually heard a little more -- same story, but maybe I did a lot of filtering and we heard some of this the last time we heard testimony, too. Let me make a real sort of simple boil down. The big, hot issues are the NDC codes, the provider classifications and the number of required fields.
There was a discussion last time that we actually were asked to -- but it wasn't necessary -- to encourage X12 to make a last real hard look on all these variables because in the consensus process it is -- you are more willing to just let it all be in there to get agreement but when you start to look at the statistical effort and the value that you are suggesting, I think that one could get -- we should do this quickly and get a judgment made and it would make more sense to shorten the list of required fields. We should do that quickly, I would suggest and save the -- you know, not throw out the baby with the bath water.
MR. MOERTEL: I agree. One comment I would make is that I have 25 high priority issues. The reason I ask that I have some somebody from this committee separate from this is I could take up an entire day describing those issues. If you would like that, I would be happy to take that on, but not today.
MS. TRUDEL: I have a page full of questions. I will get to them later.
I want to try to do the same thing that the members of the committee are doing and kind of distill this down. I heard a number of different problems, the solutions to which are also different, I think. I think there is a need that Catherine mentioned to reassess the correctness of the field sizes, the field repeats and the data elements that nobody wants anymore that by mistake found their way into the implementation guides and can be fixed.
There is an additional need that Dave mentioned to assess the business need of some of the data that is either required or situational because if the situation occurs, then you have to provide it anyway. I would quarrel with your concept of universal business need, but I will talk about that later.
Additionally, there is a need to look for work arounds. There are work arounds to some of these things. There are possibly situational definition changes, like your issue of the one indicator that is only used in Indiana. I don't understand why there isn't a situation remark in the implementation guide that says only use this in Indiana. That means that other people in the other 49 states don't have to provide it.
There are some additional ways around that. Then the question is what is left. I think there is a smaller universe, but that universe is things that we believe people do need and that we have to accommodate somehow. At that point, then, I think, vendors have to take over.
Anybody want to comment on that?
MR. MOERTEL: Just, obviously, you saw my eye go up on the comment about the Indiana issue. The Mayo health system provides healthcare coverage to people throughout the nation, throughout the world. If there is an issue in Indiana for Indiana Medicaid, it becomes my issue for my entire foundation. We serve people from Indiana. We are going to be sending claims to Indiana Medicaid if they authorize the visit to Mayo and they do.
Therefore, to accommodate those requirements, those situational requirements, I have to build my system to face that requirement, even though I don't live in the State of Indiana. That is the rub.
MS. FYFFE: Mary, Catherine, Dave and Don, the work that you put into your documents was very labor intensive and I very much appreciate the time you spent in preparing for the testimony.
Dave, picking up on your comment about Indiana, what I fear might happen in that type of situation, whether it be your organization or another provider is -- there will be a period of time where there will not be electronic claims sent to that Medicaid program. You are going to drop that stuff to paper and it could be years, depending upon who the provider is before that becomes an automated claim. And that is a real problem.
I mean, who knows? You could be sending something via electronic now to a number of Medicaid programs around the country and because of these challenges, that is going to change and it is going to go to paper.
MR. MOERTEL: And looking at it from a vendor's point of view or a payer's point of view that has to provide COB, in the interaction with that state, if it is a vendor, more than likely they have their product somewhere in Indiana. They are going to have to make modification. Every payer is going to have to make modification because if they receive a claim as primary to their insurance but the secondary insurance is Medicaid, they are going to have to respond to it.
MS. FYFFE: I have a question for Catherine, but it is possible that Don might be able to help out with this as well. You said that traditional practice management systems were developed to facilitate claim submission and posting of the remittance. These systems don't support interactive environment.
Do you have an idea like to the nearest $10,000 what it would cost for a physician's office -- you know, a physician's office with maybe five docs to acquire, lease, buy, a systems that would help them?
Let me just give you some context. I was at a conference maybe a year ago and there were some physician practice folks there and they complained about the fact that their physicians didn't want them to spend the money for a cell line because it cost too much.
In that context what kind of dollars are we talking about?
MS. SCHULTEN: I have an interesting perspective on it because I used to work for a couple practice management vendors, large practice management vendors that serviced one doctor to ten doctor physician practice. Let me tell this is a loaded question.
There are physicians out there who have purchased software to do claims submission. 800 bucks. Their palm pilot costs more than what they are doing claim submissions on. They have an extremely tight budget and they do not want to spend anything to comply with HIPAA.
Then you work your way on up the food chain to the larger physician practice, which has already invested several hundred thousand dollars in a system and they probably are thinking that they are going to have to make some investment to upgrade their system, a new version of software, for example.
They are concerned about the security issues, privacy issues. Once again, they want to make minimal increases to their systems. It impacts the smaller providers to a greater extent. I mean, the percentage is a much harder hit for them. So, there are people who will probably be looking at -- they don't want to spend much more than $10,000 to accommodate this. These are practices that are a little bit larger in size.
MS. FYFFE: Which, again, means that they are going to send in paper.
MS. SCHULTEN: Well, they will either send in paper -- it has to become -- the vendors get into sort of a catch-22 here. They need to, obviously, provide systems that the industry would want to purchase. So, they need to do what they can do to augment their system so that it is now capturing HIPAA data that makes a HIPAA compliant claim.
But some of these smaller vendors, they just don't have the big development staff and it is not going to be cost effective for them to make these changes. So, I think we might see some vendors maybe get out of this line of business or just become paper claim submission systems.
MS. FYFFE: Thank you.
MR. BECHTEL: Could I add to that comment or response?
Although I am not -- my experience or expertise is not with practice management systems in my company --
MR. BLAIR: Who is speaking?
MR. BECHTEL: I am sorry. This is Don Bechtel.
What I was going to suggest to you is that, yes, vendors need to come up and help with this and I know some vendors are doing that, that they are providing an interface to their applications to handle these transactions, to extract the data or import the data.
There are also solutions available via clearinghouses to make this more affordable and more attractive to the smaller providers. There are browser solutions that are being considered and built to help the low end providers or the small providers be able to access the information, as well as interface the results of that into their application.
So, I believe work is being done and I don't think the cost when we look at these solutions will be that high.
DR. COHN: Thank you.
Kepa and then Clem.
DR. ZUBELDIA: Kathleen, I would like to make a prediction. The TIMSS meeting is next week and my prediction is that every single vendor in that meeting will have a sign in their booth that says "HIPAA Compliant," whether they actually implement it in seconds or not, they are HIPAA compliant.
I have a concern and the concern is more for Mary, that we may be too deep in the forest to -- too deep in the trees to actually see the forest. We have been talking about modifications to the standards and I agree that the standards look like a Trojan horse. There are lots of things in there that people didn't know and after we have the standards, we are saying, oh, my gosh and that Trojan horse needs to be completely open and shaken to see what is inside and we are not sure everything that is inside.
But there are certain things that we know are not going to be modifications. You made an emphasis in the difference between maintenance and modifications. Modifications are substantive changes that would require to go through the federal process of publishing in the Federal Register and all this, but maintenance will be nonsubstantive changes and I think that the errata that have been discovered in the implementation guide should be divided along that line and say all of these errata, what are maintenance items and what are modifications.
If they are maintenance items, let's do it. Let's fix it. If they are modifications, then you need to look at it. Instead, the errata have been divided among the showstoppers and non-showstoppers. Well, some of the clearly errata in the publication are showstoppers. Some are not showstoppers, but it is clearly a mistake in the publication. It was not the intention to publish it that way.
Things like NDC versus J Codes is clearly a modification, but the things that are corrections, errata, that don't require substantial changes to the business practice -- I will give you an example. At the service line level, the referring physician segment does not allow for the name of the referring physician, only for the last name, not the first name, only the last name, in the professional guide. It has been correct in the institutional and dental guides, but in the professional guides it doesn't allow for the name, the first name.
Well, that is adding a new data element that is not used today, would be used, but I still think that clearly that is a typographical error because it is correct in the other two guides. The intent was always to have the last name and the first name of a referring physician because it is a warm body person that has both. So, I think the resolution of this needs to look at that division. What is the modification? What is the substantial change? And maybe correct all the things that are just errata and just maintenance items without going to a complicated process.
I will give you some quick examples. The dental code shows the possibility of having modifiers for the procedure code while there is no such a thing as dental modifiers. So, that should be not used.
The first name that I mentioned, some of the CPT codes, for instance, haven't ever been used in the practice and I don't think ever -- nobody has ever looked at it and the example is five digit modifier codes and the CPT in Appendix A, where it lists about all the modifiers and it talks about the two digit modifiers, Modifier 81 and 52 and 22 and all this stuff. There is something that says that instead of Modifier 81, you can use 09981. That has, I think, never been implemented by the industry in the last few years. That is legacy stuff.
That 09981 is part of Appendix A of the CPT. If the CPT is implemented as is, everybody would have to implement five digit modifier codes for the procedure codes. I don't think people have even considered that possibility. I think that was just an oversight. I don't think that is a modification that would require to go through the Federal Register and so on. I think that is just an errata that needs clarification. I think that needs to be looked at.
DR. COHN: And your question is?
DR. ZUBELDIA: My question is are you going to look at it that way?
DR. COHN: Oh, okay. Thank you.
MS. EMERSON: I am glad you clarified that. Let me just -- I will address the easy part of it, I think, first. I think that the reason for the emphasis on the so-called showstoppers in dividing the reported errata into the showstoppers and the ones that weren't showstoppers was to try to get that body that might meet the test of being necessary to be corrected in order to permit compliance.
In other words, which group of these errata would meet that test and, therefore, could be adopted in the first year? I understand that that --
DR. ZUBELDIA: That test is only for modifications.
MS. EMERSON: That test is only for modifications but you had asked why were people concentrating on showstoppers. I think that is the reason.
To get back to the other part, making a division between those things that are maintenance versus those things that are modifications, the definition in the final rule of maintenance, people have complained that this definition isn't really very helpful. When it talks about the transaction standards, it says, "Technical corrections to an implementation specification." That is really all it says.
I think that the general thought has been that if a modification would result -- would need to result in a new version of the implementation guide, that would be considered a modification rather than a maintenance. That would have -- since the Secretary adopted a particular version and publication date of the implementation guide, if that particular one were modified, it would require a regulatory process to adopt.
DR. ZUBELDIA: On your Item 5 of your matrix, it says, "Modification of adopted standards where the modification is necessary to permit compliance." That is what you are referring to, right? These are modifications to permit compliance, as opposed to maintenance.
MS. EMERSON: That is right.
DR. ZUBELDIA: So, maintenance doesn't have to be necessary to permit compliance. Maintenance could be done any time, right?
MS. EMERSON: It could be done at any time without a regulatory process.
DR. COHN: And, Kepa, just to further clarify, I think most of our views are is there is going to be -- as we put together all of these fix its, there is going to be some time that there is going to be probably a cleaned up next version of the implementation guide with all of the errata maintenance stuff fixed, as well as whatever happens with all of these modification issues. I think we would all see that, I would imagine. I think the going in assumption we have here is that --
DR. ZUBELDIA: Would the modifications imply a new version of the implementation guide and the maintenance keep the same version of the implementation guide? Is that the difference?
DR. COHN: Maybe you can help, Clem.
DR. MC DONALD: Well, I have a question and a comment, too, but what I am hearing is there is a spectrum on how this could be interpreted and I hear some people on the committee worried that this spectrum is too intensely -- is shifted far to one side, we will get gridlock. That is really what I am hearing. I don't know if we can settle that today, but I think that if we define this, if you change a dot and you have to make another publication, we are not going to be able to adapt as is necessary to make this really work.
So, I guess we are encouraging those who might, you know, define these lines to at least keep that in mind in the line defining process.
MS. EMERSON: I think there is room for that kind of interpretation. I guess it becomes difficult when you -- you know, giving your examples, this is clearly -- was not intended -- this was clearly not -- some of those things were not intended because they really weren't intended. They were mistakes. Other things were maybe not analyzed thoroughly before and you get into gray areas of how to interpret those.
DR. COHN: Dave.
MR. MOERTEL: I side heavily with Kepa's concept about maintenance and versus having a new guide with an addendum, indicating the changes, that there be changes to the guide as you have indicated. You have indicated that you feel that that is the general perception that that will happen.
I can tell you in the industry from the people that I have talked to and the people in these organizations, that isn't the expectation. The expectation is this addendum and for new providers -- I have been -- it is like pulling teeth to get some of these providers to look at these implementation guides because of the size. When a new provider goes into that implementation guide, I want it as clear as possible. I don't want them having to go to an addendum to try and understand whether this is the right thing or the wrong thing in the implementation guide. I think it should be a maintenance item.
As a simple example, Kepa, we have one area that states that we have to report -- I am going to get these backwards -- creatinine, instead of creatinene(?) -- creatin instead of creatinine and there is a substantial difference from a provider's perspective when you are talking about a dialysis situation as to which one of those you mean. It was obviously an error and unintentional.
It is maintenance that needs to be done before the onslaught of providers finally pick these guys up when they are at a point where now they are going to start implementing these things. So, I think not only should we follow Kepa's advice and take care of these maintenance items. I think we need to do it with haste.
DR. COHN: I agree. Well, Kepa, you have some examples --
DR. ZUBELDIA: There is a number of examples in the guide that are incorrect. In fact, some of them are syntactically incorrect. That stuff needs to be fixed.
DR. MC DONALD: I had a real question or --
DR. COHN: Go ahead, Clem.
DR. MC DONALD: And that is, I think -- I just want to reveal or expose what I think are two opposing thoughts. One of the thoughts is we should get a statistical boil down of what is really the 90 percentile, what everybody uses, and throw the rest out.
The other one I think I heard you say was that if someone announced it, they have to have it. I think those are fundamentally so logically in conflict and that if we are going to have simplification, everybody can't have everything they want. I don't know how we deal with that conflict, but I don't think it helps to just kind of hide it or not talk about it.
DR. COHN: Well, let me start by making a comment on this one and others may comment. But I hear there is a combination of issues coming up. Kepa has commented about the maintenance issues and absolutely I think we all agree that maintenance, misspellings, bad examples need to be cleaned up and there probably doesn't need to be a new implementation guide if they misspelled something.
On the other hand, I have heard a whole bunch of business issues, business issues that I am going to at some point ask the DSMOs how they are going to address the sort of fundamental big issues that are not just even an SDO sitting around in a small subcommittee and deciding whether taxonomy codes ought to be included or not. That needs to be widely discussed by the business and somehow a combination of these things sort of need to be dealt with.
Hence, here, I think your business issues that you are describing -- and somehow the business needs to be included and some resolution needs to occur.
DR. MC DONALD: But even higher than that, even now, really there is this ongoing view that we have these standards. Now we get all the data we want in. We have heard this throughout all the testimony and there is not -- each person who has these needs has these needs, but they may not be for billing. I kind of heard that today and the other side of it is and it has probably more to do with Medicaid than other things because they have something -- variant inputs, but can we -- this is a systems thinking. You want to say, well, let's find a 90 percent -- I will say this was required because these other things if most people don't require them, they may be a little bit on the edge.
Then we would have something really easy and everybody would be happy. Now, those -- except, you know, the ones who are on the 10 percentile. But if we really are setting out to say that we are going to do both of those things, I think it is not realistic. I don't think we are going to end up with simplification. I don't think we are going to end up with happiness and I think we have to face the conflict. I think what it amounts to is people when they are thinking on their own, yeah, I would like to have it, I would like to have it, but when they are really pushed back on, well, how badly would you like to have it.
Because some of these data requests are actually impossible because of the work load realities and the -- if they are asking on -- you know, depending on where it happens, it is not available. We ran into this in the ambulance attachment. They wanted to know what -- from the ambulance driver, whether the patient was admitted or not. They don't know. It happens, you know, six hours later, twelve hours later. So, it gets really hard when you go I would like to have this one in, but you have to make it somehow. And those people that make it are stuck in a mire. They can't get it.
I guess I would be for saying let's try to get it cut down to what -- you know, some high percentile need and -- but we have to hear from what does that do to everyone else who wanted those extra variables.
DR. COHN: Well, but, Dave, isn't that what you were proposing in some ways, taking these issues --
MR. MOERTEL: Exactly.
DR. COHN: -- and sort of asking the SDOs to talk to the industry and see if these things are really needed and to what level.
MR. MOERTEL: I could not have stated it better.
DR. COHN: So, you are agreeing with that position basically.
DR. MC DONALD: I am really worried that we are talking -- all nodding and saying different things. I wanted to get -- propose the fact that some people are saying, well, by God, I want the color of the eyes and I am not giving up. I just need it for something or I might need it or I want it. And then other people are saying, oh, gee, we can't make it happen and somehow get that resolved. I don't know whether there are just crazy ones or they are imbedded in laws in states and whether the HIPAA will override that so that it doesn't secure -- in privacy.
MS. SCHULTEN: That is actually what a lot of these crazy ones are is that they are laws in the states. When I was -- in the past, a customer I used to work with had a requirement for military eligibility, military enrollment. The requirement for a person in the military for eligibility and enrollment are much different than, obviously, the civilian community and, yet, these are requirements they have to have it. They are forced because it is CHAMPUS that they have to comply with HIPAA. So, they have got to put those requests somewhere and it stuck in 834s and it got stuck in eligibility requests and there was no other way to accommodate it.
So, there are very unique business issues that have been forced into transactions that in 90 percent of the industry doesn't affect them, but where else were they going to put it.
MR. BECHTEL: But these were also -- I am sorry -- this is Don -- and just to comment back to that, those are situational elements. They are not required elements. So, the situation is he is in the military; therefore, I need to supply more data.
I think that is workable, although, you know, the transaction is built to accommodate all this stuff. It doesn't always have to have all that stuff. So, we need to look at the situations when we are applying this test.
DR. COHN: Jeff, did you have a question?
MR. BLAIR: I did. It is on a slightly different topic here. So, I could save my question if there are still people that want to resolve the current discussion.
DR. COHN: Okay. I see Mike Fitzmaurice's hand raised. So, we will hold your --
DR. FITZMAURICE: First, on the current discussion, following Don's comments on situational. I am from Indiana and I think we are fairly reasonable people. So, if Indiana Medicaid says they need a variable and it convinced the standard developing organization. I am inclined to think that maybe it is reasonable. But to hear a complaint that we are going to have to change our systems in California and Florida, in Minnesota and other states because of a situational element, that is what systems are for. Can you imagine the problems and the manpower you would chew up if you didn't have a system that prompted, alerted and reminded you that, hey, this fellow is from California. Are we going to have to send to Indiana, Blue Cross and so you -- or Indiana Medicaid, so you are going to need this variable? You would have people flipping through pages for every state to seeing is this an Indiana Medicaid or is it a New Mexico Medicaid.
It seems to me there are benefits to systems. Some of these are business issues that show the advantages of systems and the advantages of standards not glitches to be overcome by changing standards necessarily. I agree with Clem that we have got to balance out making systems do everything against making them work for 90 percent of the people. But let's look at the tradeoff of the costs. The costs of the manual processing of those exceptions versus the cost of systems processing and make a business decision.
Then, finally, how can standards help get to the most cost efficient solution?
MR. MOERTEL: Your final comment, Michael, is the critical one. Those exceptions are going to have to be handled manually. The reason I say that is in order to accommodate those situational elements, either I have to set up my system all the from the practice management system to the medical revenue system, the patient accounting system. All those systems have to be in alignment and have that data available.
I have no problem with creating a map to transport information and to include situational data elements. The difficulty is I have to have that situational data element available in all of those systems to automate these processes. If we have those situational elements, yes, those are going to have to stick out. They are going to have to be manual.
My whole expectation behind the administrative simplification process is that we could truly automate these systems and not have to run into those manual affairs. What I am trying to do as manager of electronic commerce for the Mayo Foundation is to eliminate the manual effort, not create it. What we are doing by having those situations is creating that manual effort that wasn't there before. These are new situations where a new manual effort is now required, but it can't be what we were trying to achieve.
DR. FITZMAURICE: But it wasn't caused necessarily by the standard. It was caused by Indiana Blue Cross mandating a certain element before they would pay the claim.
MR. MOERTEL: Indeed.
DR. FITZMAURICE: You have to handle that manually one way or the other, but with a system that prompts an alert on this. It reduces the manual processing a lot. I ask that as a question. You are the systems expert.
MR. MOERTEL: I am not a systems expert. I am on the business side. I have electronic commerce folks on my staff, the IS personnel or information services personnel that handle those types of things, but I agree, I am close enough to the systems that I know we can have those prompts.
My point is is that I was hoping we would achieve systems that would not require that manual intervention.
DR. COHN: Okay. Karen, I think has an issue on
-- then I want to let Jeff have his question and let's try to put this together. I don't know if we have time for a different topic.
Karen.
MS. TRUDEL: I would like to ask Margaret and Maria how the DSMO organization would go about assessing whether there is or is not a significant or universal business need for the pieces of data that are at issue here.
MS. WEIKER: Actually, the DSMOs don't assess -- the DSMO organization, each individual organizations, X12N, NCPDP, HL7, et cetera, assess the business need in their deliberations. So, I mean, the DSMO as a group doesn't do it. Each individual organization assesses is there -- what is the business need. Is this truly something universal? Is it because Medicaid agencies, as an example, use that data element today and that is done in each organization for the SDOs. It has to be done in a consensus type of manner.
X12 each, like the 837, has a separate work group. The 270, 271, has a separate work group and those items that pertain to that particular transactions are discussed in that work group. Unfortunately, there may be times where the group may be more heavily payer represented or provider represented, those type of things, but that just sort of naturally happens. So, each individual SDO and each group that may look at something assesses those business needs.
DR. COHN: Right.
Jeff, do you have a question in relationship to this one, because I want to give you an opportunity to ask the question but I also want to push on this one a little bit. Is your question in relationship to this, Jeff?
MR. BLAIR: No. It is with respect to what I think what Don Bechtel was mentioning in terms of the way WEDI/SNIP has laid out the time frames for coordination.
DR. COHN: Okay. Well, let's hold that one and then let's push on this one for a minute here.
Margaret and Maria, you have heard obviously a number of issues that have come down and actually Karen was already leading into this discussion. Obviously, what we are hearing is a complex sort of milieu of some maintenance issues, which probably can be handled almost without much thought. We are hearing some issues having to do with sort of verification of business needs, which are a number of slightly different and related things, I mean, questions of does industry need it at all and, if so, what is the percentage and how do we make a decision about all of that.
I think you were just mentioning that it is not the role of the DSMO to decide all of those business needs. Yet, it is, I think, in our view, the responsibility of the DSMO process to facilitate that as a discussion getting back to the right SDO so that that issue can be brought up and reflected on.
Now, we are unfortunately under a little bit of a time line and what I keep -- and as I tend to think of all of this, gee, you are asking vendors to go out and create systems and you don't want to have them completely finish up their systems with all of their things if suddenly we are going to be having SDOs reconsidering that they really didn't need necessarily all of the data elements.
So, I guess the question I have for you is as we begin to look at these things, knowing that now we are moving from a level of Lee Barrett, who was here back in November was saying, gee, it would really be nice if the SDOs could take a last look at the implementation guides and make sure that everything that is really required to aim this at specific data elements where there are questions. I mean, is this something that a process can occur within the SDOs, facilitated by the DSMOs to try to get some speedy resolution to this? I mean, knowing that things are not going to be perfect and that the DSMOs I don't think have a way to handle really legitimate business needs that may exist in Indiana or elsewhere -- sorry, Clem -- but at least can observe them and observe the level of that business need, but it may be that some of these things really aren't needed at all or maybe were needed three years ago and nobody is at the table now that wants them.
So, I think that is sort of -- I mean, the question I have is can you handle that. Is that something that can be handled relatively quickly or in a reasonable time frame to sort of move this process forward?
DR. MC DONALD: Sort of a spin, not on that -- I mean, somebody should come up with a list of proposed get rid of data elements, at least those that aren't required because right now we are talking sort of in the space world.
Now, the question about legitimate business needs is an undecidable thing. It is like being on a formulary committee. Everybody wants their drug on, but someone has to say "no." So, we have got to have some naysayers somewhere in this process to push back and I don't see, frankly, why you have to have the pregnancy code for a bill -- I mean, do we get mixed quality -- we get a lot of stuff mixed into this billing now that isn't really classic billing. I can see why you need to know the code for CHAMPUS because that is an insurance code. I mean, you have to know who to charge to, but I think one could look at the set of them and see if we couldn't push back.
Now, what I don't know is is there ability in HIPAA to ask the states to relax something just because it makes it so hard? If we can, it is the privacy. We can't do it anywhere else?
DR. COHN: I don't think so. I guess, to me, the question is is -- I think the SDOs, first of all, need to do -- find out what the case is around all of this stuff. Then they need to find out if it is even still needed anymore as people reflect on it and realize that maybe the providers are questioning whether they are necessary because sometimes that does provide some feedback and then they need to understand the case for which that data element is necessarily the amount of implementation that we have been talking about. I think that may help.
Kathleen, am I causing problems?
MS. FYFFE: Just clarification. What or what can we not tell the states? I mean, I thought that there was some language in the law that said that for administrative simplification that the federal law preempted -- Kepa, thank you --
DR. ZUBELDIA: The standards preempt the state requirements, as far as getting additional data elements for the claims and so on. This has already happened with the type of service code. If the claim doesn't have a type of service code, the states were all up in arms saying we need it, we need it, we need it, but it turns out they already found their way around it. They don't need it.
If the pregnancy indicator is needed in Indiana, even on Mayos, they probably don't need it because it is something that doesn't change for every claim. It doesn't change more often than every nine months or so. So, if it is not in the implementation guide, the state will have to find a way around it. So, it can be taken out of the implementation guide and then it is the state's problem, how to find a way around it.
MS. FYFFE: How do we extract it from the implementation guide?
DR. COHN: That is not our job. I think that is a job for the SDOs to review it first and provide some input.
MS. FYFFE: I was sort of asking the question in theory not --
MS. WARD: This might speak to that and also kind of go back to your initial question, Simon.
First of all, I think that the lines are kind of gray between this thing we started in X12 in November called an errata initiative and the role of the DSMO, as it was laid out in the MOU and whether or not, rightfully so, our role has expanded to take on changes to the existing implementation guides within that one year time frame. There was never a predetermined, pre-agreed to this is the charge of the DSMOs.
Now, it may be the right place for that to happen and that is something we are discussing as a steering committee. We are working very closely with HHS and X12 is a member of the DSMO steering committee and they are involved from an X12 perspective in everything we are doing with the DSMO steering committee. I mean, we need to determine -- and it goes back to part of Kepa's explanation -- we need to determine what is a modification or a showstopper, what is maintenance or a technical correction. Which goes down which path? Which affects which time frame constraint? Which affects got to do it right now and which affects can be in the next version or the subsequent version?
I think it is also important to understand from an implementation perspective it is not just about down the road that vendors are going to, you know, considering design and system specifications to create HIPAA compliant solutions. It is already happening.
I mean, I am working with health plans that are in the implementation and strategy phase. They have done their analysis. They are preparing to develop designs for their systems. It is happening right now. So, if what we do to these implementation guides results in either changing, you know, references to external code sets, removing data elements, doing any of that stuff. It has to happen very quickly because you are going to have a lot of people that are halfway down the path and have to turn around and undo everything they did to redo in a different manner.
DR. COHN: Thank you, Maria.
MS. WEIKER: And to follow up, Maria and I -- the problem is everybody is at different stages in this analysis. Dave and his group of people, they have got their list. Maria, as well as my role in the IS, there are people who are actually going in and already modifying their system. So, now we come out with an addendum or something where we change. Now they have got to go back and do analyses, you know, and they have already spent millions of dollars. Now we are going to make them go back and do it again.
But an issue is we have got to get all of it identified now. I mean, most everything I have seen that Dave's group came up with is 837. On the errata web site, a lot of it was the 837, but there were other transactions that had some issues with them as well. But it is where is the point where we say no more. Deal with it. Implement it as is or put in a modification and we have got to fix it later.
But as I said earlier, Maria and I can push the fact that we have got to go back and look at these business needs, but the thing is how many times do we have to keep going back and doing it? We have got to get it done now and say this is it.
DR. COHN: You certainly agree with what I was asking and the question is is can we do that.
Dave, do you have a comment specifically on this point?
MR. MOERTEL: Yes. The Secretary put sort of a benchmark time that we have to face up to and that is one year after the original rule was brought forward. So, that really is our time line at this juncture, that we need to get these things in place before then.
But the comment that I wanted to make was something that Clem and Kepa and Kathleen, I believe, commented on and it is the fact that many of these data element requirements, the 10 percent, the reason they are in the 10 percent is because 90 percent of the industry is doing it in a different way. Why can't the 10 percent do what the 90 percent are doing.
An example: The reason why the baby birth weight isn't required is because there is an ICD-9 code that indicates that this is a low birth weight baby and that is why the costs are higher, why it was premature or whatever. That is the way the industry is handling it. Why because of one group do we have to change that philosophy when it is working the other way for 90 percent of the industry? So we can accommodate the 10 percent? I would say "no." So, there are work arounds for those 10 percent. Those 10 percent are not going to be left out in the cold.
DR. ZUBELDIA: I would like to make a request and see if the DSMOs can do this. There is a process to request modifications. That is a DSMO process and modifications that will go to a next release of the standards. That is a DSMO process. I haven't heard of a clear process to request maintenance and, obviously, you are getting maintenance requests in the DSMO process.
You are also getting questions on policy issues that you are directing to the Department without touching, but you set up a process to deal with modification requests as opposed to maintenance requests -- I am sorry -- you have the modification -- you set up a process to deal with maintenance requests, but maybe reacted to the Department, maybe reacted to Washington Publishing as the publisher of the books, whatever you want to do.
You set up that sort of process so we can a maintenance request.
MS. TRUDEL: Based on the matrix that Mary presented earlier, I think we felt based on the regulation and the definitions of maintenance and modification that the maintenance of the implementation guides, which after all belong to the standards developing organizations who develop them is appropriately in that venue and those organizations, as I understand it, all have existing processes for taking care of maintenance items.
So, I would hope that the DSMOs would -- the web site would send them to the proper place once it is determined that something is maintenance opposed to modification. What I heard Clem saying earlier was that the recommendation is that we reassess the dividing line between the two and make it a little bit more workable.
DR. ZUBELDIA: Can I agree that it is a very short definition of maintenance? Maintain or maintenance, the first two activities necessary to support the use of the standard adopted by the Secretary, including technical corrections for an implementation specification and enhancements or expansion of a code set. This term excludes the activities related to the adoption of a new standard or implementation specification or modification to an adopted standard or implementation specification.
So, it sounds to me like short of adopting a new standard or a modification to a standard, everything else would be maintenance, including code sets.
MS. EMERSON: But then adding a new code or within a code set would certainly be maintenance. Adopting a new code set would be a modification or a new standard.
DR. ZUBELDIA: But most of the items that we have seen so far are just maintenance.
DR. COHN: Kepa, I would actually disagree with you. The testimony I heard from Dave Moertel sounded actually mostly like modifications. Maybe I am hearing different things. It is a major mix of the two. I mean, you don't get rid of taxonomy codes or the taxonomy field and consider that to be a maintenance item.
DR. ZUBELDIA: I agree that taxonomy codes, the birth weight and the pregnancy indicator and so on are modifications, but if you look at the bulk of the errata that had been worked on, they are maintenance; 99 percent of them are maintenance.
MS. WARD: See, Kepa, existing requests that are on the DSMO web site, I would say are requests that would be considered modifications, not maintenance. So, in that context, what is out there is probably appropriately routed to that web site and, honestly, I agree with you, Karen, and I am hearing you actually both say the same thing and I think from our perspective we agree with you, Karen. If it is an issue that can be handled within the SDO, that is where it needs to be handled. It is not technically a DSMO process issue if it falls under that maintenance definition.
But from an implementation, the rest of the world, the people who aren't sitting in this room, the real problem is educating people and understanding that. What is the difference between maintenance and modification? What is this DSMO process? What is it supposed to do? How is it supposed to work? What is this errata thing and what does that have to do with the DSMO process? I mean, that is the confusion out there.
That is the real world view of this. That is what people are experiencing.
DR. COHN: Okay.
Now, we are running a little bit over and I think we all sort of -- I mean, we are all sort of commenting that whatever it is that we need to do in terms of review of the relationship to some of these business issues, the modifications need to occur relatively rapidly. Do you want to think about it over the next little bit, I mean, as the next couple of hours and come back with some ideas as we move through the day about what you think a reasonable time to help facilitate all of that is, recognizing that yesterday would have been very convenient, knowing that is not the case. But before the end of the day we should reach agreement on what we consider is a reasonable time for that process.
I think we all wanted to expedite both maintenance and clarification around second look at some of these more vexing data elements to make sure the SDO has got an adequate chance to review them. Certainly, data elements are typically business issues, which may be why they really do fall into the DSMO and need to have everybody have a look at them.
Jeff had a question that is off on a different topic. Jeff, would you like to ask that question? I apologize. We have been sort of off on a whole set of different issues.
MR. BLAIR: Sure. Don, you had indicated that WEDI/SNIP had tried to assist in laying out things in a step by step manner where there could be some degree of coordinated testing of each of the different transactions and that when you did that, the time frame significantly exceeded the two year time frame for us to be able to pull that altogether.
Could you tell us a little bit more of what you did, what it looked like? You said you would need some kind of a different tool or something else to help you to be able to consolidate these time frames or coordinate them more effectively or efficiently. Could you please tell us a little more about that?
MR. BECHTEL: Yes, I would be glad to.
As far as a tool was concerned, what we were speaking to was the testing phase.
MR. BLAIR: There is a wonderful, effective air conditioner over here and your voice is lovely but it is soft. So, that is the reason -- and I really want to hear your words.
MR. BECHTEL: What I was saying is the tool that we were talking about was for the test process. We were looking for a way to do certification so that organizations can become certified as to meeting certain obligations of compliance so that we don't have to continue to repeat that test with every trading partner.
Okay. If we could find a way to validate the work that is being done with a trading partner is compliant and meets the obligations of HIPAA, then they should be able to go to any trading partner and say, you know, I have met these certification requirements. We don't have to go through that testing again. That is not to say we don't want to do some testing with every entity. But maybe we could eliminate a good portion of it so that we don't have to do this repetitious work that elongates the process.
So, we are trying to find a way to bring the time line of implementation to a shorter window. In terms of the sequence proposal that we put out, we did put a proposal in place that met the criteria of the HIPAA completion date. So, we were looking to be done by October 16, 2002. We have kind of worked backwards from that date. You know, we would have to do these transactions in this sequence to accommodate that.
The push back that we got was we were being too aggressive. Some organizations felt we were trying to start the testing and the implementation cycle too soon and they couldn't get there fast enough because they were waiting for vendor systems to be ready or whatever else. Then we also got the push back that, all right, if we delay the start to a time that meets some of the vendor obligations, can we get it all done in a timely --
MR. BLAIR: -- I mean, was it just a few months or was it longer?
MR. BECHTEL: It is a pretty broad range and I don't really want to suggest that these are good physicians, but some of them, we would go another two years. At least that is what they were proposing. I am not sure that is reasonable and I don't think it is necessary, but that is what they were saying.
DR. COHN: Any other final comments on this one?
DR. ZUBELDIA: Along the same kind of line of thought, Don, you mentioned the possibility of having the code sets implemented at the very end and having some time to implement the transactions before everybody reaches all at once the new code sets. Have you guys thought about a way of designating that hybrid implementation that would be X12 compliant, but with still using old code sets?
MR. BECHTEL: It is something the work group is beginning to talk about, but we have not come that far yet, but, yes, I think it is something we would really like to look at and try to find a way to do that. I personally believe it would help.
DR. COHN: Okay. Well, we will now get back to our normal running, about 10 to 15 minutes late.
I actually want to thank the panel. It has been a fascinating, very useful conversation. Maria and Margaret, hopefully, we will see you as the day progresses.
[Whereupon, at 12:15 p.m., the meeting was recessed, to reconvene at 1:05 p.m., the same afternoon, Thursday, February 1, 2001.]
DR. COHN: The first afternoon panel and session
-- this makes the second panel for the day and is dealing with NDC issues in relationship to the institutional and professional claims. I want to tank all of you for coming. I think, George Arges, we are asking you to sort of lead off the discussion since I think you are the one who brought this issue to the subcommittee's attention.
MR. ARGES: Thank you. I don't know if you can hear me okay?
Let me begin by thanking the members of the National Committee on Vital and Health Statistics for inviting me to be here to at least convey the concerns of the NUBC around the use of the National Drug Code. For those of you who aren't familiar with the NUBC, we are one of the four organizations mentioned in the HIPAA administrative simplification provisions for a special consultative role in the development of HIPAA standards.
Additionally, we are also one of the signatories to the recent memorandum of understanding for the maintenance of the instructional guides on the transaction standards, part of the HIPAA DSMO group.
The NUBC considers itself basically a data content committee that primarily focuses on the institutional health care setting and as a data content committee, we examine new requests for data, along with the business rules that will govern its collection. We examine the purpose of the requests, the associated benefits and how best to capture the data. Often, our examination process includes the entire membership of the NUBC, representatives that serve on the committee basically are the major organizations representing government programs, such as Medicare, Medicaid, Tri-Care.
Other representatives come from the payer, institutional provider, public health and health research sector. We also include representatives from standard development organizations, such as ANSI ASC X12 and another data content committee, like the National Uniform Claim Committee.
When the transaction standards and code sets were published on August 17th, it called for the adoption of the NDC codes for the reporting of the drugs and biologic items within the transaction standards. When we learned of this new requirement, NUDC was very concerned about the intended use of the NDC and sought clarification from the Department of Health and Human Services.
NUBC, as a result, submitted a letter dated September 22, 2000 -- I believe a copy may have been supplied as well -- voicing its concern about the ambiguity of the final rule around the intended use of the NDC, particularly with respect to the institutional provider sector.
At a joint meeting that we held with the National Uniform Claim Committee, the NUBC heard similar concerns that were voiced by the NUCC, as well, the concerns around the adoption of the NUCC in lieu of the HCPC J Codes. They were asked basically to provide some answers to some of the questions that would help, I believe, the NCVHS have a better understanding of the issues and problems that we are facing.
One of the questions asked is what are the problems that would arise if we revised the standard to allow J Codes to be used for institutional and professional claims and what are the costs of converting to the NDC codes versus staying with the J Codes.
Today, the institutional professional providers are reliant on HCPC J Codes to report drugs; therefore, allowing the continuation of the J Code for use among the institutional provider sector would not pose any major problem. >From our perspective, it is the change from the HCPC J Code to the NDC that would impose the most significant hardship for providers and payers alike.
The primary reason for our concern is the significant cost associated with the widespread adoption of a brand new code set like the NDC. The adoption of the NDC will require extensive conversion and replacement of existing information systems, as well as associated training costs in working with a new code set.
Cost estimates indicate that adopting the NDC alone could easily exceed the conversion costs of adopting the new transaction standards. The costs would vary, depending on size of facilities. We have heard some estimates from hospitals, which put the price at a minimum of about $200,000 per facility.
We note that neither the proposed rule nor the final rule included a cost benefit analysis that indicated what the costs would be for the adoption of the NDC outside of retail pharmacy.
Another question that was asked was whether hospital pharmacies use NDCs or HCPC J Codes in their operations. During the course of our investigation, we found that the NDC has very limited use within the hospital pharmacy departments. Its primary use is for the purchase of the drug but even here it has a very narrow application.
In other words, it begins and ends simply as a reference to the purchase order and is used mostly for inventory control. However, another important issue that was brought to our attention centers on the potential harm that could occur to patients as hospital pharmacies would be required to transition their systems to an NDC.
Pharmacy departments told us that that would require the need to build new interfaces with their dispensing systems. So, the concern was whether the dispensing systems that would be required to adopt the NDC would get the job done correctly. The failure in terms of referencing the correct NDC could cause a medication error as well.
Furthermore, the hospitals who often repackage and provide unit dosage do so differently than how the NDC was coded and, therefore the nature of the drug itself is different. So, hospitals provide drugs that are compounds from different drugs. So, there is no comparable NDC in those instances.
So, under these circumstances, the NDC may not be readily available or even exist. So, trying to implement an NDC on a claim basis, provided at the time of the purchase would not necessarily correspond to the way that drug was dispensed to the patient. Consequently, the NDC would add significant new operational burdens for caregivers without corresponding savings.
There was another question that asked are there drugs and biologics that are reported without HCPC codes, which are included in the transactions. Today, we note that payer representatives on our committee have told us that they have no particular use for the NDC and feel comfortable with their continued use of existing HCPC J Codes.
Generally, the payers are satisfied with the current reporting of the HCPC J Codes and pharmacy revenue codes. But there are instances where the HCPC codes are not useful for drugs and biologics. Mostly in inpatient claims where the reporting of the pharmacy revenue -- where the drug, the pharmacy item, is reported as a revenue code without a corresponding HCPC code.
A revenue code captures the services of a different category. In this case, it would capture all the drugs furnished to the patient during the inpatient stay. The reasoning is that payers, like Medicare, rely upon perspective payment systems to reimburse providers for inpatient services.
Such payment methods are primarily based on the ICD-9 diagnosis code to drive payment and for Medicare, it will result in one of the predefined DRGs. Whereas, other payer representatives also indicated that their bill review and payment processes will not benefit from the adoption of the NDC. Their review is similar in nature and is based primarily on the entire set of resources used to treat a disease or illness.
So, for inpatient hospitalizations, again, the NDC codes are key elements. The only time payers would need regular specificity is if a particular type of drug or biologic item is furnished under special circumstances. Generally, for these situations, the trading partner agreements defined what items need to be reported. But here, again, it is the HCPC J Codes that are primarily used for this purpose.
In the event that a HCPC J Code is not available, it is fairly understood that the code itself needs to work through the process, the HCPC process, in order to get it assigned to a new HCPC J Code category.
In summary, the NDC from our viewpoint was never intended for hospital use. It was designed for the out of hospital setting, primarily retail pharmacy. We are asking the NCVHS to make a recommendation for a correction to the final rule, primarily for institutional and professional claims. We will recommend that they be allowed to continue to use HCPC J Codes for the reporting of outpatient pharmaceuticals and biologics and that the NDC should only apply to retail pharmacy claims.
Again, thank you for allowing me to address this issue and I look forward to working with the NCVHS on this important matter, clarifying any other issues later on.
DR. COHN: George, thank you.
Betsy Humphreys.
MS. HUMPHREYS: Before I start, I would like to acknowledge that we have with us today some of the world's authorities on the NDC codes. In the back corner there, we have Randy Loven(?), Cathy Morocco and Herb Gristenzine(?) from the FDA. So, if we want to complicate this matter with details about NDC codes, they are here to fill us in.
Also, I believe, that you should all have received in front of you a paper that says, "National Drug Codes on Standard Transactions, Background for February 1, 2001." If you haven't, I am sure we can find one for you.
I am going to address this issue at a fairly high level in order to leave the maximum amount of time to hear from our testifiers, who are telling us what is really happening in the world. I just want you to know that this is quite a detailed analysis of the various things going on. The people who prepared it don't want credit, but they deserve it, in my opinion.
So, you have what I am going to tell you at a very high level, but you have a lot more detail about what some of the ins and outs are, the nastier side things of this issue are.
Basically, after receiving the comments from the NUBC, which have been well summarized here, and the other groups that commented on this, the Department and those involved with developing the transaction reg went back and reviewed carefully all the comments submitted after the publication of the final rule, but also went back and reanalyzed and restudied all the comments that were received after the -- in response to the NPRM.
Basically, after looking at this, we realized that there was -- more research and evaluation was probably warranted for this issue than had been done between the receipt of the comments on the NPRM and the publishing of the final rule. The goal of having a singular, more granular and frequently updated code for drugs and biologics, we still feel is a fine goal. We are, based on the comments that have come in in this further analysis, believe that there are serious issues, which have just been enumerated, some of them, for us in terms of the timetable for when we could move toward a single drug code across the way.
We believe that in some sense the impact has been more clearly stated in a way that has really coalesced these issues for us, based on the comments that have come in from the industry as they are really grappling with how would they implement this. So, the more recently received comments are, in fact, a clearer explanation of what the issues and problems are than some of the earlier ones, although these issues were, indeed, raised earlier.
So, basically, we are -- I don't think anyone is quarreling that the NDC code is the appropriate code for prescription drug and retail pharmacy transactions. We have come to the conclusion, as did many of these commenters that we need to do more evaluation with respect to the use of the NDCs on the other standard transactions. In the meantime, it may be the most advisable course to just go back to -- or to change the recommendation to say leaving the J Codes or the institutional and the provider -- the professional claims.
Two points we need to or a couple of points that we need to be clear on, we do think that the process that is being put in place for rapid or reasonably prompt development of national interim HCPCS codes will address one of the issues, which was problematic before, which is when we looked at all the local HCPCS codes that had been developed across the country, a fairly high percentage of these, in fact, were drugs, which is one reason why it seemed a good thing that the NDC code, which was rapidly updated as drugs became available, might be a solution to that problem.
But the problem is no doubt still going to be there in terms of the annual update cycle, but this interim process that HCFA is putting in should address that, which, I mean, at least in the interim.
The other issue is that this is a rule change. This needs to go through the regular rulemaking process. This is not something that can be changed at the level of implementation guide. So, we are talking about going through a proposed rule process. Karen can talk to this better than I, but there are possible approaches to expediting this, but it kind of depends on a number of factors, including whether this might be folded in with proposed changes in other areas that come up as we, you know, really get down to cases or the people who are trying to come up with the implementation get down to cases.
So, I think that is kind of the summary of where we are on this and there is a lot more ins and outs of the details of this in that paper, I think, pretty clearly expressed. I would answer questions or we might more productively use your time by listening to the people who are really worrying about this issue.
DR. COHN: Why don't we do that and then we will do questions afterwards.
Don Bechtel.
MR. BECHTEL: Let's see if we can get the volume right this time.
DR. COHN: Don, if I can make a suggestion, if you keep it on that side of you, you actually might find you could do better. Part of the problem, I think is that you are talking off to the side.
MR. BECHTEL: Thank you. I am still Don Bechtel and I am still working for HDX and on behalf of HDX and my parent company, Siemens Health Services Corporation, I would like to thank you for the opportunity to testify today on issues related to a National Drug Code with institutional and professional health care claims.
HDX and Siemens Health Corporation have been analyzing the impact of administrative simplification on our services and products since the initial NPRM was issued for transactions and code sets. Generally speaking, we are very pleased with the rules and look forward to their full implementation, as we believe these changes will greatly improve our efficiency and effectiveness at handling the associated business functions.
However, there do remain some issues regarding how the industry will implement the required changes in an efficient and orderly way. One of those issues is the concern for using the NDC in place of J Codes when reporting drug charges on an institutional or professional claim.
NDC versus J Codes: The HCPCS J Code provide a simple way to report high cost drugs and biologics generically, without reference to manufacture or package size, but specifically to administered dosage. In the institutional and professional settings, this is a simple, efficient and effective way to report this information.
The National Drug Codes were not designed to accommodate reporting of drugs administered. These codes lack specific information related to dosage and the X12 transactions that will utilize these codes lack instructions for how to specify dosage amounts administered or dispensed as they relate to the package.
The NDC is much more appropriate for supply chain functions to track and order inventory. As I am sure this committee knows, these codes are assigned with reference to manufacturer, drug and packaging characteristics, which are not always equivalent to the dosage or prescriptive orders. Although the NDC can be referenced when filling an order, packages may be broken or subdivided to fill the order when dispensing a drug.
There are other issues related to these codes that have been widely publicized, such as the field length differences between NDC and J Codes, frequency of changes to the codes and code reuse. These are all valid concerns, which will require changes to many systems. Storing codes that are double the size that we currently keep will impact storage requirements, require application file enhancements to accommodate the field length and the granularity of information.
Maintaining these files will require more frequent updates to the code sets to stay current with the coding additions and deletions. These are not vendor or developer problems, but they may inadvertently increase operational costs to the provider.
These things being said, there are advantages to using the NDC code, especially in the pharmacy environment. We see advantages to some payers who may be able to determine more accurate reimbursement for providers based on drugs dispensed or administered. However, for the institutional and professional goals, we see little benefit for the changes that will be required to support these in terms of application enhancements or operational procedures that will need to be implemented.
The following examines this from several perspectives in this environment.
Institutional systems within a hospital enterprise: Most hospital enterprises are complex environments composed of multiple applications and systems, each focused on specific functions within a hospital unit or area of business and often many are supported by different vendors. Examples are patient are, laboratory, radiology, pharmacy, patient accounting and patient billing applications to name a few.
These systems and applications normally exchange information between certain processing or trigger events, for example, when a physician's medication order is entered into the patient care system, it would generate a message to the pharmacy system to fill the order.
When the order is completed, information about the drug dispensed may be sent to the nursing station or the patient accounting financial applications or both. These data exchanges normally occur within a hospital enterprise by way of HL7 or by proprietary messages. Unfortunately, in many cases these are still proprietary messages or proprietary implementations of HL7 that are being used to accomplish this processing.
I am sure this committee is very familiar with the process I have just described and I only note this to help define the problem that will begin to occur. Notably, there are HL7 messages that accommodate the above processing between applications and these can support the NDC to report the drugs that are dispensed -- what drugs were dispensed and/or administered.
In most hospital environments there are many vendors supporting these various systems, but not every vendor is using HL7 in all of these communications, leaving proprietary messages to be changed or HL7 to be implemented to accommodate this use of NDC. Neither one of these is a simple task and, more importantly, this is not a single vendor issue. It will require cooperation between multiple systems and vendors, who may choose to solve these interface solutions differently as there are no governing implementation guides for this purpose. The key point is that the above will require application changes, time and a lot of coordination for the provider to implement, but on the other hand, it can be done.
Processing flows for pharmacy and drug orders: There are several processing flows to capture drug charges that are utilized by different providers, depending on the level of sophistication they have implemented with these interfaces. These examples would be a clinician enters an order into a patient care system, which sends the order to the pharmacy system. The pharmacist fills the order and the pharmacy system sends a charge record to the patient accounting system.
In this example, capturing the NDC information can be done easily be included with the information that is sent to the patient accounting system. In another situation, the clinician enters the medication order into a patient care order entry system, which sends the order to the pharmacy. The pharmacist fills the order and the pharmacy system sends the order fill information and administration instructions to the nurse station. When the nurse administers the medication, the patient care system then sends the charge record to the patient accounting system.
In this example, NDC information may be available to send to the patient accounting system if the NDC code was included in the order fill information. In some systems when the clinician enters the medication order into the patient care order entry system, both an order is sent to the pharmacy system and a charge record is sent to the patient accounting system.
In this example, the NDC information for the drug used to fill the order is not available to the patient care order entry system. So, no NDC information can be included on the charge record, which is sent to the patient accounting.
To get the NDC information in this third case will require some other method to be created. For example, the pharmacy system could send the NDC information to the patient accounting system when it fills the order. Then the patient accountings would have to associate the NDC information from the pharmacy to that of the charge record that was sent from the patient care order entry system.
This would be a significant task and not one we would recommend. Alternatively, this third approach would be eliminated, which would require procedural or re-engineering of interfaces with a new enterprise. This may also require application enhancements elsewhere in the environment.
Institutional pharmacy systems: When an institutional pharmacy system dispenses a drug for a physician's order, the system will know the NDC code for the drug. This information can be sent to the patient accounting system when the drug is dispensed. But the patient accounting system will have problems when the package has been subdivided.
Further, the pharmacy system will have a problem reporting when an order is split between two packages when the supply of one drug is diminished and another is opened of a different package size or the manufacturer, it is not clear how this information would be reported. Also, we should note the cocktail drug situation that was described by Dave Moertel earlier.
Another point that needs clarification, which drugs must we capture the NDC information for? Is this to be limited to the drugs that would normally have had the J Codes or is it to be all drugs? the rule is not clear on this, but since in an institutional setting we only report J-coded drugs, is it reasonable to assume we only need to capture NDC for the equivalent drugs. Clarification in the rules on this point would be helpful.
Application changes to support NDC information with ordered, dispensed or administered medicines will require changes to HL7 implementations or proprietary systems, which could be expensive, complicated to implement and will probably require process re-engineering.
From a pharmacy perspective, NDC codes are used for other purposes. So, supporting the code would not be a problem. Use of the NDC could be beneficial for auditing purposes if we could have consensus on how dosage information and split packaging is accomplished. This needs to be understood with implementation guidelines such that the patient billing applications can correctly itemize the charges and the pharmacy systems can send appropriate details.
Patient accounting and financial systems: For the purpose of this testimony, I am defining these to be where the patient billing applications are maintained and run. Charges for patient bills are accumulated by the patient accounting system, which track number of days, room charges, et cetera. Charges for drugs administered to the patient are captured by either proprietary charge transactions or a combination of HL7 messages from pharmacy and patient care systems.
The patient billing applications capture and accumulate charges and then based on the type of bill, inpatient, outpatient or professional and the type of payer, it determines how to present these charges on the claim form or an electronic form. In the institutional setting, most charges are summarized into a revenue code assigned for a DRG or an APC, which would include medications. J Codes are used to report certain high cost injectable drugs for chemotherapy on outpatient bills.
Today, most HIS patient accounting systems are not capturing the NDC codes. To do this will require changes to the interfacing systems just described.
The NDC cannot easily be captured at the nurse station. Often, the packaging is unavailable and generic brands may have been substituted. Therefore, more extensive use of HL7 or proprietary messages may need to be implemented between the pharmacy and the patient care and the patient accounting applications to capture meaningful data.
Algorithms will need to be developed in the patient billing applications to determine unit pricing from the information based on dose administered versus package information from the NDC. It should be noted that there are no standard implementation guidelines on how these HL7 or proprietary records should be implemented by various systems or vendors, but application changes will be needed in several systems to implement these changes for the HL7 messages or proprietary messages that would be used. This can become very complicated and many of the implementation specifications might not be known for some time, while vendors develop their solutions.
Reporting drugs on an institutional X12 837 claim, there are several problems associated with this. First, currently with the DRG or APC administered drugs are not normally listed as a line item. Rather, they are part of a summary charge, which is rolled into a revenue code; although, some high cost drugs are itemized using the J Codes. The dilemma is when to the NDC. Is it only for these high cost drugs or is it for all drugs that are administered?
The other problem is reporting partially used packages. As noted above, it is possible that drugs to be dispensed from the pharmacy or taken from a larger package and then subdivided.
Professional environment: Practice management systems will have the same issues as just described for the patient accounting applications, except many of these are not interfacing with the institutional pharmacy systems. So, in many cases, the NDC information will need to be entered at the practice management system manually.
Using NDC codes will be awkward at best for billing injectable and intravenous drugs in the physician's setting. This is for the same reasons we have just described in the institutional setting.
Other questions we were asked to address after this testimony was prepared, so I put these at the end.
What problems would arise if we revised the standard to allow J Codes to be used for institutional and professional identification of drugs instead of NDC?
For both institutional and professional settings there would be no problems or expenses incurred if the J Codes were used in place of NDC, since we currently support the J Codes today. However, a quick decision will be helpful as we are now in the process of making our system modifications. If this change is not needed, it would be good if we could stop the development before too much time is spent on this activity.
Are there drugs and biologics without HCPCS codes, which are included in the transactions?
The answer I was given for this question is that the HCPCS coding system does not support all drug types. The J Codes only address chemotherapy and injectable drugs, not all the drugs that might be administered to the patient. In the institutional environment currently, it is only necessary to identify chemotherapy and injectable drugs, primarily for Medicare, due to the high cost and the need for separate reimbursement considerations.
No other drugs require coding in today's institutional billing environment. If the NDC is implemented in the institutional billing environment, the question becomes: Will it be necessary to identify all drugs administered?
Conclusions: The NDC codes can be used, our systems can be modified to support this processing, but at what cost and for what benefit? We are not sure what the benefits are to capturing this information. We are not sure that we have consistent implementations to calculate the information needed to produce a bill.
We lack adequate instructions for how to report information on the claim when package sizes are not equivalent to doses administered. We are not clear on what drugs need to be ordered and when or need to appear on the bill and when.
Our current plans are to build the necessary support to handle these processes described above. However, we believe there will be implementation issues between the different vendors and the transaction trading partners. The implementation guidelines will need to be improved to address these issues.
It is our recommendation that J Codes should not be eliminated for institutional or professional claims. We believe these were created to specify high cost drugs that were administered in a generic way, which has already simplified for billing. To replace the J Codes with NDC codes will make a simple process less simple.
That ends my statement. Thank you very much.
DR. COHN: Don, thank you very much.
Mark McLaughlin.
MR. MC LAUGHLIN: Mr. Chairman and members of the committee, I am Mark McLaughlin, a regulatory policy analyst from McKessonHBOC. McKessonHBOC has long been considered a leader in the healthcare software industry. The many diverse solutions offered by McKessonHBOC today make integration a real and everyday challenge. McKessonHBOC solutions include software for payers, hospitals and providers, as well as other functions, such as claims clearing services.
It is through those diverse system solutions with McKessonHBOC that we also see diverse answers to the J Code/NDC code issues. All McKessonHBOC systems have performed a gap analysis on the issues, specifically surrounding the transformation from J Codes to NDC codes. Systems such as the pharmacy system or the home health system will see very little impact as those systems deal with the NDC codes today. This will have a moderate impact on the clearinghouse as the output to all of the payers will need to be changed.
This impact is not solely due to the J Code/NDC code issue. However, the impact remains moderate regardless. The interfacing system from the Hospital Information System to the clearinghouse will have very little impact as this system will simply pass through what is sent. The impact grows as we begin to look at our hospital information system, payer and clinical practice management software.
For McKessonHBOC HIS systems the NDC information will need to originate from the pharmacy systems. There will be changes to the charge interface records to include NDC code coming from the pharmacy. The pharmacy system will need to be changed to send the NDC. It is possible that some pharmacy systems will also send along the J Code to keep from having to do the look-up at a later time. Most all of the HIS systems will carry both does throughout their system.
While this allows for easier tracking and history archive capabilities, the development effort is expanded. The development will need to be duplicated as it relates to the J Code and NDC code fields. Allowances for interaction with non-integrated systems is a key area of concern for these development organizations.
Some systems will have to require that any third party pharmacy system sending a charge record, now send the NDC code in that charge record. The NDC will be stored for the patient's charge in the patient accounting system and the NDC code will then be passed to another system for distribution to the clearinghouse or direct to the payer.
Since we represent many of the larger institutions throughout the United States and we send source code to our customers on the mainframe, we are very aware of the time line to institute the final rulings for the 837 institutional and professional transactions.
We have always been very progressive in our products to support the Federal Regulations. Our products for our business units span the product line pharmacy, patient care to patient management or ADT, medical records, chart tracking, patient accounting and many interfaces to products internal and external to McKessonHBOC, both inbound and outbound transactions.
Our customers typically pick and choose what module modifications they implement. We are going to have to require them to be on the latest main release for implementation of this change, since it is very widespread throughout the product. This will put a major effort on them to implement this one change.
Some of our customers do not have our internal pharmacy product, but rather have another pharmacy, with an in-house written interface to send charges. This will be an additional burden to our customers to implement this modification as those interfaces will need to change. A normal release implementation is over a six month time frame.
The typical time frame for development from the HIS standpoint may run up to 190 person days per product.
McKessonHBOC payer systems: The development effort is larger for payers than anyone else. They are tasked not only with enabling all of the transactions electronically, but they have to deal with these issues related to the cross reference of NDC and J Codes. It is the extent of that effort that has given them cause to develop a short term solution, as well as a long term solution.
The elimination of J Codes from the payer perspective will be a major issue as they have tied reimbursement and benefit adjudication to HCPCS J Codes. Changing these codes to NDC codes will require a great deal of configuration by our payer customers. In the short term and in an effort to enable our clients to be compliant with the transactions and code sets final rule as soon as possible, some payers will initially translate from NDC to J Codes to continue adjudication from the J Code.
The payer customers will also need the capability of translating back to NDC. Therefore, some way of retrieving the original NDC code will be necessary. The payer customer services area will need a tool for looking up that cross reference information in the short term. As they face inquiries from customers or submitters, they will need to be able to reflect accurate information as it relates to the submitted transactions. If the code set is an NDC and it was converted to a J Code, they may need access to the original data in order to resolve those problems.
In the long term, the payer systems will change to adjudicate from the NDC codes. The typical time frame for development from the payer system standpoint will run between 50 and 180 person days per product.
McKessonHOC clinical practice management systems: The practice management systems will have a very large undertaking in allowing NDC codes to be processed through their system. Expansion of fields in nearly every module within the software will need to take place. NDC codes will be stored within the system and the system will have the capability to display the NDC code so customers can match the line item to the payer remittance.
These systems will also be able to pass the NDC code through the charge record so it will be passed to the clearinghouse and on to payers. Subsequent maintenance and distribution of the NDC tables is of great concern to this development effort. As yet unanswered questions are: How will updates to NDC codes be distributed and how often will customers need to run updates to their software and how long will these updates take?
These answers will be very critical to the plans of this development group as well as the implementation team. The typical time frame for development from the practice management standpoint is nearly 395 person days per product.
As you can see, there is a fairly substantial impact on our software development efforts. While the systems mentioned above will more than likely address the majority of the issues related to the topic, they are simply working within the existing rules. It may be obvious that utilizing duplicate drug codes may not be the most efficient use of a developer's time, nor will it be the most efficient use of the provider's time.
Continued use of the existing J Codes may help to ensure a timely implementation. Certainly, a more efficient one-to-one cross reference of the J Codes may be needed to accomplish this daunting task in the time frame required.
I would like to bring to light other issues that will be shared by these developers as well as all of the providers and payers. One-to-many cross reference, HCFA has contracted with a third party to produce a cross reference table that would allow a person or a systems to access a J Code and cross reference that code to one or more NDC codes. There are many issues associated with that scenario and that extends the development time in such an effort. The development systems may need to deal with the solution in different ways.
If a provider has non-integrated vendor systems in place, the implementation issues become more complicated. That being the case, the interfacing systems will also need to be looked at and modified. It is possible one system's solution to the problem may be to determine the correct NDC code through a look-up and selection process, passing the single code through to the next system.
If the receiving system would accept both the J Code and the NDC code to be passed, we are now missing important information, that of the original J Code and that may be needed later. This issue becomes more and more complicated with every additional system that touches the transaction.
If, for example, the systems are only sending one NDC code throughout the process and that NDC is passed onto the payer, it is possible the payers system may convert that code back to a J Code for internal processing and benefit adjudication. If the transaction information would ever need to be reconverted back, however, that would be impossible to do without the original NDC code.
The NDC number is a smart number. The number designates the manufacturer, product name and packaging information. The NDC is also commonly used by pharmacists today so the packaging information is meaningful in that setting. The packaging information, however, may be less useful in the provider or payer setting.
An example: If an NDC is designated for a particular box of ten vials of a drug, the pharmacist may dispense the box or vial, 1/10th of a box. However, in a clinical setting, the provider is giving an injection from one bottle of that box of ten and the NDC number can no longer be used for billing.
It is possible that the units may be used in some instances. However, that would require a calculation to decide how much of the vial was used and issue those units by the fractional unit. Units are not always the answer however. Not all drugs are billed at the service line level so the solution is only selective. The NDC number may be sufficient in the pharmacy setting. However, there are problems with that usage in the hospital and clinical settings.
As mentioned above, HCFA is working on a cross reference file related to this issue. I am not sure how effective that file will be. It is possible that if nothing more than a one-to-many cross reference developed in the first draft of this file, that its use may be very limited. If HCFA is successful, however, other issues, such as distribution will need to be decided.
The NDC codes change on a more frequent basis than the existing J Codes. How will the NDC codes be distributed? Will they be downloaded from a government site? And will that be weekly, monthly, quarterly? The frequency will have a large impact on the effort imposed on the provider and payer organizations.
Today, NDC codes are distributed through First DataBank or what is called the Red Book. Licensing is required for those distribution methods and those methods are not always perfect. An example is going back to the tray of ten 1 gram vials of any particular drug would use the NDC number of the tray, showing it as representing ten times 1 gram vials. The same NDC number would also be used on each vial. For First DataBank to send us pricing information, they must decide does the NDC number represent the tray or the vial?
As you can see, there are many problems associated with this change. Lengthened development times, usage and functionality problems, extended implementation time frames and potential distribution issues to resolve. It is the hope of McKessonHBOC that this committee will be able to assist in setting the issues straight. that may be by utilizing a code that will work for the pharmacies and providers and payers. That may also be utilizing the functionality that works today by retaining the use of the J Codes.
I would like to also address the other four subsequent questions that were sent to us. What problems would arise if we revised the standard to allow J Codes to be used for institutional and professional identification of drugs instead of NDC?
As mentioned in my testimony to this point, it would actually back off all of those hours of development time that I mentioned for each of those products. So, it would be easier.
Are there drugs and biologics without HCPCS codes, which are included in transactions? Yes. In the institutional as George and Don both mentioned, sometimes the use of revenue code is -- codes are used.
What are the costs of converting to NDC codes versus staying with J Codes?
Again, going back to my presentation, noted all of the hours of development time, it would cost just millions in development time alone.
Do hospital pharmacies use NDC codes or J Codes in their operations today? I believe that they -- the answer has been in all presentations at this point. They do use NDC codes and J Codes.
I would like to thank you for the opportunity to address this subcommittee today. That is the end of my testimony.
DR. COHN: Okay. Mark, thank you very much.
MS. MILLER: Sue Miller from IDX. I am their corporate regulatory and compliance manager. I am also involved in WEDI/SNIP, but not in the electronic transactions area. I am a co-chair for privacy and security. I want to thank the committee and the subcommittee for inviting me to testify today.
IDX develops and implements innovative information systems that help its customers to be more successful at improving the quality of care, serving patients more efficiently, reducing costs and more effectively analyzing their businesses. IDX products are used daily by more than 118,000 physicians. IDX products are installed at more than 2,000 customer sites nationwide, including more than 265 large group physician practices, with an average of 303 doctors per group.
IDX has been investing in the HIPAA area for the past two years. It has an overarching HIPAA team with dedicated teams for its product sets and services and its internal structure with dedicated domain experts from each of its five business units engaged in the HIPAA work.
IDX fully supports the general intent of the electronic transactions and code sets final rule. We believe that the complexity of the new regulation in converting from HCPCS J Codes to NDC for a large number of our customers may make it very difficult for them to meet the implementation date of October 16, 2002.
Almost all of IDX customers are impacted by this new HIPAA regulatory requirement. The survey of our customer base and our products informs us that our physician practice customers currently are using J Codes almost exclusively. The survey also informed us that we have hospitals and specialty groups that are using both in our products and other products NDC and J Codes.
IBXtend, IDX's practice management product is the most heavily impacted as it only uses J Codes in its current version. IDX LastWord, which is a hospital product, has a pharmacy module, has two pharmacy modules, that use both NDC and J Codes and passes either to the billing system. IDX radiology product allows the customer to set or enter or use either NDC or J Codes to pass to a billing system.
The questions that you have asked that I have outlined below will have a multiplicity of answers as it will depend on what the provider has used historically, not just what the vendor has given them to use. There is no one-to-one match between the code sets. You have heard this before. I am just repeating what everybody else has said.
There seems to be a temporary fix that might be possible, using an ANSI X12 "fudge" by putting or assigning a new manufacturing code to a J Code to make it look like an NDC code. I consulted somebody who is very active in this area about this.
Now, to the questions. Have you or your organizational members performed a gap analysis to compare the drug and biological data you have available electronically with requirements that are contained in the HIPAA transactions? If so, what are the gaps between the data elements, code sets, and the electronic information?
IDX is in the middle of this gap analysis in its product sets comparing the drug and biological data currently collected to that mandated by HIPAA and within the implementation guide for the 837.
The HIPAA requirements to move from HCPCS 7 Codes to NDC is a very significant impact on IDX software and our medical group practices customers' processes. The IDXtend product line is directly impacted by the mandated code set change. The product line is used by approximately 100,000 of these physicians that are our customers. The requirement includes mandated changes to the IDEX product in dictionaries, screens and reports.
IDX other product sets are not as heavily impacted. There appear to be minimal problems for IDX radiology product and for the LastWord hospital pharmacy module.
Is the gap a barrier for you to implement the 837 standard? If so, what are your plans to resolve the barrier?
Yes, the change from the HCPCS J Codes to the NDC for professional and institutional 837 is a significant barrier to both IDX and its customers. Substantial changes will have to be made to the products and their associated databases.
IDX will need to enhance its product set by adding new dictionary fields and screen/report fields and field length in the database to support the NDC codes.
These are the other four questions that you sent at the close of last week.
What other problems would arise if we revise the standard to allow the J Codes to be used for institutional and professional identification of drugs instead of the NDC?
It is IDX opinion that for some people in industry, it will further confuse an already complex situation, especially if it is the Department's future goal to move totally from J Codes to NDC codes. We have already started this process on the vendor side and, you know, you may be telling us to pull stuff and go someplace else and that is difficult.
With the need for an industry approved crosswalk between the two code sets and more work at ANSI X12 for the NDCs to be of value to many of the covered entities and to support the efficiency and the interoperability goals of the HIPAA administrative simplification, the "how" in the Department's comment with these additional questions and the time frame should be carefully considered.
IDX supports a considered and time sensitive move from HCPCS J Codes to NDC provided the additional items that can now be included in J Codes will be included in another code so that our customers will be paid for the provision of those services.
IDX supports the standardization and billing of all codes, code sets.
I am just repeating in the other questions what I have repeated in my other testimony. I thank you for permitting me to testify. I am willing to answer your questions.
DR. COHN: Okay. Well, thank you all.
Are there questions from the panel? Kepa.
DR. ZUBELDIA: I would like to ask everybody on the panel if you think that the J Codes and the NDC are mutually exclusive or if they can coexist with each other. Is it possible to send a claim with a J Code for payment and an NDC code for reference?
MR. MC LAUGHLIN: I believe they coexist today. As the pharmacy systems today are dealing with NDC codes and all of the rest of our products for the patient accounting system and those types of systems are dealing with the J Codes. Are you suggesting that they coexist in the same settings?
DR. ZUBELDIA: In the same claim. The reason why I am saying this is -- and I am sorry we don't have anybody from home infusion today here, but I understand home infusion is very vocal about needing the NDC codes for correct payment because there is not enough granularity in the J Codes. There are certain situations like that that there is enough granularity in the J Codes and they need the additional information that the NDC codes provide.
Is it possible to send a claim, an 837 claim, where if the J Code in the service element of the claim and an NDC code in the ref(?) segment that says this is the drug or biological that was used for this J Code? It may not be for payment other than for home infusion payment, maybe just for reference and only when it is needed. I mean, is that possible? Will that solve the problem?
MR. ARGES: You are asking if it is possible. I guess there are two dimensions to the question. I think anything is possible. The question is the cost associated with providing that additional piece of information and the value that would be derived from it. Not all departments that provide, say, your pharmaceutical item, at least at the hospital level, will have the information about the NDC code available to them. It basically goes to the charge master and you may not know the manufacturer. It is just an item that is pulled from the pharmacy department and dispensed.
The unit may be indicated and in instances where there is the need to report a specific J Code, it is only then that the J Code is reported, but in other cases, it is simply a revenue code that is indicated and is just reported on that basis.
DR. ZUBELDIA: In that setting, in most cases, you will have a revenue code and nothing else. In other cases, you may have a revenue code with an addition of a J Code. What I am saying is maybe you would also have a revenue code with an addition of a J Code and an NDC code, if necessary. I am not saying it would be there all the time, but in cases like home infusion and other cases where you actually do need to have the additional NDC code, maybe provide a mechanism to actually convey the NDC code in the claim, without requiring it, maybe a situational or optional, and then revert back to J Codes for billing.
Is that, I mean, possible? Of course, everything is possible --
DR. COHN: I am just not sure I have got the problem well defined yet and you are already moving toward the relevant and complex solution.
MR. ARGES: Let me answer a little bit further here. For instance, let's say an aspirin is needed. There may be an NDC code for a Bayer aspirin versus an Anacin. But for the charge master, I don't know that there is that specific level of detail that is needed to basically report that item, nor do I see the pharmacy basically conveying to the unit that is receiving the drug that it is a Bayer that I am giving you versus an Anacin. All I know is I am giving you an aspirin of such and such dosage in tablet form.
DR. COHN: Maybe I should start with sort of a more basic set of questions here. George, let me ask one or two questions. I am just trying first of all to understand the issue you are bringing forward to the committee. I know that you really represent the National Uniform Billing Committee, represent institutional providers.
I was actually mulling about the uses that you really have for pharmacy and pharmaceutical codes. I don't consider myself to be the expert in hospital or hospital outpatient billing, but I understood both from your testimony, as well as I understand the practice, that it is a very rare circumstance in which a J Code or an NDC code would likely be used on a hospital inpatient UB92. Is that correct?
MR. ARGES: That is correct.
DR. COHN: I mean, it might happen but it would be a very, very unusual circumstance.
MR. ARGES: That is correct.
DR. COHN: Now, in the case of hospital outpatient with the advent of the APC rules and all of this, once again, J Codes typically aren't being asked for because they are all -- I may be wrong on this one. So, help me with this one a little bit. But my understanding is is that these things are being rolled up into APCs. There are certain biologics and drugs that are high pay biologics and drugs that are actually in the C Codes that need to be listed otherwise.
But under this new APC rule, likely, they aren't going to be required there either. Am I correct or am I mistaken on that?
MR. ARGES: That is correct. There are C Codes that are used for the APC outpatient that are basically drugs or biologics. So, the question then becomes you are maintaining two systems as well. If you were to require NDC and HCPCS, you would have HCPCS C Codes to report some of the drugs under APCs.
DR. COHN: Okay. Well, I am just sort of wondering what -- once again, I am just trying to identify the issue here. So, we are saying for the inpatient hardly ever or sort of not quite the --
MR. ARGES: People are buying --
DR. COHN: -- and outpatient C Codes are being used, but they are going to be rolled up eventually into APCs, as HCFA gets an understanding of what that is all about and is able to sort of put them into new APCs. So, that is going to sunset over the next couple of years. Correct? I am trying to figure out what the -- see, I am talking about what your issue is so we can help deal with your needs.
MR. ARGES: That is correct. I mean, typically, a third party payer doesn't need to see that level of specificity in order to make payment. You are paying for the treatment of a disease or illness. You are not paying for a drug necessarily on its own.
In the outpatient setting for some of these items that are specific in terms of keeping track of costs associated with either new or high cost items, there is the need to include that J Code, but eventually even those will find their way into the APC payment and, therefore, the need for specificity drops once again with those.
DR. COHN: Okay. Do you actually need to report those J Codes to then get rolled up or do you just report the overall APC?
MR. ARGES: For those, you report the J Code.
DR. COHN: I am just trying to figure out the issue here.
MR. WHITE: David White here from --
DR. COHN: I appear to be asking pretty specific questions here. I know enough to be dangerous and not enough to be an expert.
MR. WHITE: My name is David White. I am a pharmacist by background and I live OPPS, APC coding almost everyday in the corporate environment that I work with on the pharmaceuticals. There are J Codes, Q Codes, C Codes and A Codes at this point in time. They are related to the pass through list for APCs, which are basically a carve-out for additional reimbursement. Those are not rolled up into the additional APC or in APC like a normal pharmaceutical would be. Okay? And those aren't going away.
That is what I am hearing that we are going to switch over to an NDC number for those particular sets and that set is probably at about 200 codes or so right now. That is updated on a quarterly basis by HCFA and then we go in and modify it, add changes, deletes and such, as these quarterly bulletins now come out since August of last year.
But those codes are reported on the outpatient claims all the time since August of this year. That is what we code in charge masters at this point in time. Generally, those codes do not come from the pharmacy system. Some pharmacy systems do allow them to be able to pass, but generally they are hard coded in a patient accounting system.
When a chart transaction comes across from a pharmacy system or an ancillary system, you get a record of the number of units and the charge code associated with that particular product. It matches the charge code in the charge master, the numerical number that represents that particular product.
The NDC number is nowhere associated within a patient accounting system at this time within the environment that I am working with and in a large multi-hospital network. So, it is very difficult to perceive how you would then be able to get that particular subset of NDC numbers to a client and only those NDC numbers. Either they would have to be hard coded in the charge master, like the HCPC code is at this point in time because it is not just J Codes. There are a wide range of them.
So then now you are talking an expansion of a field in the charge master or the patient accounting system to accommodate 11 digits, dashes and such. So, that concept to me is very hard to understand how we can move toward that.
I have heard a lot of -- and they are correct as far as passing information from pharmacy with the interfaces being rewritten and such, but generally from a patient accounting standpoint, only those posed that are required under OPPS are coded. There are a lot of other valid HCPC codes, but they will reject the new claims editing systems, like 3M software if it is not a valid OPPS code. It can be a valid HCPC code for physician billing or if you know the billing, but if it is in an institutional patient accounting system that is going to reject in the claims editor. It is not related to OPPS at this time.
DR. COHN: Okay. Let me play back what I am hearing from you. So, the issues that you are having with all of this, we are talking about 200 actual billable codes in HCPCS codes and you are talking about mostly being an issue of internal tracking because that is really where most of the capturing of the J Codes go in all of that.
So, for example, if HCFA got word of J Codes, it would not impact your billing, but it would impact your internal charge capture. Is that what I am sort of hearing?
DR. MC DONALD: The pharmacy systems aren't -- all the baggage in detail and knowledge in the pharmacy system doesn't play here. What typically you will have is like in cancer where they use a J Code. They will check a box saying, you know, I saw -- one box where I did a chest x-ray in one box where I gave them whatever the heck, that becomes an internal billing code and there is a simple map out of -- so, it is just sort of a different stream. They are not talking to each other.
So, they don't have any idea necessarily what NDC code that was given out at that time. So, it is just as -- there is a little tiny spigot in this little charge code, which is carrying on and it is coming from sort of a different source.
So, I think what I am hearing is it practically doesn't work and your solution wouldn't be useful as it is currently constructed. I would actually suggest further is that there is a lot of work -- I mean, I think everyone thinks a good drug code would be wonderful for lots of clinical and other -- as well as eventually billing and management and outcomes management purposes and if we -- and NDC has got some -- it is the only useful -- I mean, it has got a great -- but if we are going to be talking about clues, we should maybe try to wait until we get this better thing, which is maybe going to be out in a year or so and then revisit all this and try to find ways. That can be delivered as part of the clinical data and whatever other information along with -- and then the system would have time to adapt to it.
DR. COHN: Clem, I actually sort of agree with you and I guess we should have comments from everyone --
DR. MC DONALD: One thing I want to clarify is we are really not talking about -- we are talking about both in two different contexts. There is no talk about not having NDC in the community pharmacies where this is sort of the keystone of their operation. Is that correct?
And one other kind of spin is that I think the reg as it is written now says everywhere in the HIPAA standards you have to use NDC. That creates problems in the context of some other messages, which may be like in some of the proposed attachments, which say current drug use, which is something taken from the patient as a history. There is no way you are going to get NDC codes out of them, you know, to know, well, with the 75329087 -- you know, sometimes it is hard enough to get it for digoxin. You know, it is the pill I take twice a day is what -- so, there are some other issues as the broadness of this current statement in the regulation.
DR. COHN: Sure. I guess I just would comment and then we will go back to the questions. What I was doing was digging because, I mean, part of the issue is is whether you need to maintain J Codes. I mean, is maintaining J Codes the issue or is maintaining something else the issue? I was just trying to decide in my own mind from the testimony since you had all been referencing J Codes primarily, whether the world would be fine or not if we got rid of J Codes, but left people -- allowing people to use other parts of HCPCS or not.
What I am hearing is is that it wouldn't because it is an internal billing issue that you need to continue to track the data.
MR. WHITE: We have to -- in order to bill under OPPS, we have to code appropriately with whatever HCFA defines as that particular billing increment for that particular product, underneath that J Code, that we would have to maintain that all the time according to whatever the latest bulletins are for that particular product.
DR. ZUBELDIA: I think it goes back to this lecture that we got from Karen in our package on the maintenance of the code sets. If the J Codes are the ones to be used, somebody needs to maintain the J Code table and there is high volatility in that table. It is a lot of work and it is not just for Medicare. It would be for the entire industry.
That is a problem that at some point needs to be addressed.
DR. GREBERMAN: I wanted to ask my colleague, Randy Levin, if he might make some comments, basically bringing the group a little bit up to date maybe on some of the NDC issues, but also since we are thinking about a broader applicability of some of these coding capabilities to see if we can bridge some of these gaps because -- and what might be gained by having the NDC and/or its more user friendly version in the future possibly available to the community.
MR. LEVIN: We have been hearing some of the issues about NDC codes and NDC numbers and we have been working on the regulations for these numbers and how we would affect some of the changes. So, some of the issues that you brought up as far as deficiencies in the numbers, we are working on to address in regulation changes. So, that will help.
The other thing is that in -- we are looking into medication errors and some of those issues. I think she brought that up as an issue as well. We are looking at the possibility of the NDC number being helpful in medication errors as well and looking into the possibility of bar coding the NDC number on even the end of control unit doses that would be something beneficial in a hospital.
I mean, these are the issues that we heard from the hospitals, that this might help with medication errors. So, it may be that in time that the NDC number would have more of an advantage in the hospitals and they might use it in their systems for this so that each unit would be bar coded and you would use that when you are dispensing, even at the nurses' station or something along those lines.
DR. COHN: George and then Mike.
MR. ARGES: I just wanted to also make a comment that one thing we need to keep in mind, too, is the physical structure itself. If it would be possible to look at, let's say, the NDC number where a portion of the number itself would have utility to stay within some the existing structure. That would be very helpful. If it could at least identify let's say the type of drug being issued and perhaps the -- I am not sure that the manufacturer is always necessary in the situation, but at least the type of drug. That would probably go a long way.
But my concern, though, too, is there are some physical structures that have to be rewritten, just based on the physical size of the existing number itself.
PARTICIPANT: Right. I understand that.
DR. COHN: Mike Fitzmaurice.
DR. FITZMAURICE: I am seeing a very large disconnect here in the functions that a drug code would be used for. As we move into the electronic age, the disconnect that I see is you need a drug code for business inventory tracking. This was mentioned in Betsy's paper. You need it for clinical treatment, physician orders of drug, usually by name and so many cc's, for example.
You need it for billing purposes in order to get paid for it. But it is not the same number. The NDC number comes up so far and then the drug is ordered and clinically given to the patient. You call it by a name and so many cc's and it may come from a 1 liter bottle. It may come from a 20 cc vial.
Then you have to call it something in order to get paid for the dose that you gave the patient. It seems to me that no number is good right now, but what is needed is a number that follows that drug all the way through and you get paid for it. You might have to adjust the number based upon the dosage, like we just -- a physician's office visit is a relative value scale, maybe a level, in order to get the right payment to the physician, do the same thing for drugs. But as we try to reduce errors in medicine, we are going to need to identify the drug in the middle so that we can link it with information and feed that back to the decision-maker to reduce overdoses, to make things legible, to look at complications from that particular drug.
So, a number is going to have to use a lot of purpose. HIPAA is focused on the billing part, but streamlined transactions. But in the information age, we are going to have to look at a lot of other functionality for business purposes. It is good business to track inventory right through to billing. It is good business to identify the drug and get information to take better care of the patient and it is good business practice to pay people what they should be paid for doing it.
So, I guess the question would be who should design the better drug system? How should it be pulled together? Is this something the industry would do? Is it something you see that the government function should be? Clearly, the need is growing stronger and stronger. It is not getting any weaker.
Any takers?
MR. ARGES: To me, there is a cost associated
with --
MR. BLAIR: Could you identify yourself not only for me, but also for the people on the Internet?
MR. ARGES: Sure. This is George Arges and, again, I chaired the National Uniform Billing Committee.
I guess there is a cost associated with taking it to that nth degree and I guess there has to be, I guess, an analysis done as to the merits of moving everything under one sort of structure that way and what the benefits would be in doing so, you know. But then you can look at why stop at the NDC. I mean, why not have supply items and use the APC number and report that as well?
I mean, what is it you are trying to do? We are trying to look at this in the context of the existing transaction standards and what it is one is trying to accomplish with respect to that. Fundamentally, the drug itself, for all intents and purposes, is not the commodity that is being purchased. The commodity is the treatment of the disease and illness in its entirety and many payers basically have set some limits around that payment method and they look at it on the inpatient basis, based on the ICD-9 codes and look at it in terms of the entire set of resources rather than just a component of an item.
Similarly, outpatient is moving in the same sort of direction, but the question is there value -- there might be value in doing that but I also think there is a high cost of doing that and I think you have to weigh that cost in the long run with what objectives you will achieve in the end and whether those objectives are worth it.
DR. FITZMAURICE: I agree that efficiency in billing, order one payment for one unit of medicine, whatever that is, but it is hard to get good clinical efficiency and business efficiency unless somebody is taking care of the details, looking at the details of the drugs that are given to the patient, tracking that through the process by which it is given to the patient and the payment is made.
That may be beyond the scope of HIPAA, but it is not beyond the scope of the advice that the National Committee could give to the Secretary in terms of what are the needs for healthcare data policy and healthcare data.
MR. BLAIR: I think we need to clarify something here because I think that there is a short term immediate problem with respect to the financial and administrative transactions and the specification of the NDC codes in acute care institutional environments here, where you hear three major vendors that represent a good part of the marketplace saying that they feel like they need relief here and they don't see the value of going to NDC codes at this point.
That is a short term immediate problem whereby if an answer is not provided shortly, that they are going to wind up having to invest a good deal of money and time and their customers will have to invest a good deal of money and time. I am trying to separate that out because I think that Michael's point is also very, very valid, which is the need for a clinically specific reference terminology for drugs, that could support patient care and other applications, as well as billing.
Michael, you just tell me whether -- you know, how you feel about this, but my thought is that that is something I think we need to look at on a longer term basis in the patient record -- in the patient medical record group and in other things that we do with respect to the UMLS and we could go on and on and on because there are several forums that are working on that.
I sort of feel as if we tried to attack that now, that we won't be answering the immediate need of the folks that are testifying to us, that are saying give us some immediate relief and just leave us with the J Codes until we could wind up going to something that is more clinically specific.
DR. FITZMAURICE: Jeff, I agree with what you said and I will make it short.
Basically, there is a short term problem and a long term problem. I just want us to be aware that there can be a long term cost to adopting a short term solution that isn't going to fit.
DR. COHN: Rob Kolodner.
DR. KOLODNER: Well, in the past, the committee has made recommendations regarding the need for a component-based coding system. In fact, there have been some recent explorations of that with VA and DOD -- it was VA and FDA and NLM and CDC, some discussions that have been or will be occurring. Randy Levin has a little bit more of the information about that and I think that if we are saying there is a long term solution that is consistent with what we have been recommending all along, we ought to look to see how we get to that, while also responding to the short term need and not putting in something that is high cost and not providing the value.
Or we may want to say something about the long term so people at least have an idea about it, but it doesn't have to be -- when you are talking long term, it isn't huge long term.
MR. LEVIN: This is Randy Levin from the FDA.
What we are looking into is a way to code based on the structure of the ingredient. So, if we take the ingredient at the ingredient level and from the structure we can provide a code and we are working with, again, with Rob and the National Library of Medicine to look into a system that would do that and identify that ingredient to other features of the drug, like the dosing and mechanism of action and other features along those lines, as a way to provide some of the things that Michael was talking about.
DR. COHN: Maybe if I could ask an additional question about that? As you have all described, NDC has a couple of little flaws in what we are talking about. It doesn't give you an idea of dosage. You know, it is basically packaging issues. It doesn't include the view of dosage and all of this stuff.
MR. LEVIN: The NDC number does -- I mean, it incorporates the dose, the potency or the active ingredient. That is part of -- if you change that, you will get a new NDC number. If you take the NDC number, the labor code and the product code, those two parts of the NDC number, that doesn't have anything to do with packaging. It just has to do with the product and the manufacturer.
So, those are the types of things that maybe are a little misunderstood about the NDC number. So, those are --
DR. COHN: Maybe I am not asking the right question. People came up with multiple examples of a vial of drugs at a certain strength and when a part of that vial is administered --
MR. LEVIN: External packaging and internal packaging. So, we have a number of dose units that are packaged inside of -- you have a package and you have many vials inside that package. What you will have is a little NDC number for that large package.
We are looking into correcting that issue and the unit doses, the inside doses have their own NDC number. So, that would address that issue that you are talking about.
As far s this other ingredient code, that would be able to be incorporated or joined with issues like dose and dosage form and other things like that that would allow you to have all that information. It focuses on the ingredient, though, at that level of granularity, which is a lot different than what the National Drug Code does at this time.
MS. HUMPHREYS: The thing that is interesting here, and I think Jeff expressed it very well, is short term relief versus the longer term solution, which would be far better than what we have now, which is essentially a J Code, which is totally a billing code and only addresses a fraction of what is actually being delivered. So, if you want to deal with it for any clinical purpose, it is no good; I mean, you know, error detection or whatever.
Then you have the NDC code, which is down at a level of specificity, which is so product oriented that it is new to many practitioners and not what they know or what they prescribe. If we have had the thing in the middle that related all the NDC codes to the thing that was clinically meaningful, then the clinical and meaningful thing could be automatically -- could automatically generate a proper billing code. Instead of us having to worry about the 11 digit codes and the six digit thing, we would actually have a continuum where we could correctly read an NDC code and say, oh, I know what the patient got and run her algorithm because the clinical thing would be, you know, connected to that.
Then we could also say, oh, the patient got this, which maps up to a proper billing code and we have the bottom and we have the top, I mean, if you do it, where the -- it is more general and we don't have the thing in the middle and if we had the thing in the middle, we wouldn't be arguing about the length of codes in some -- so, the correct solution would actually be a more easily implementable solution, I think, at least as I understand this now.
That leaves a stress point, which is if we have the potential for a correct solution, which is also easier to implement, then we probably don't want -- any of us want masses of millions being spent to implement a less desirable solution in the short term.
DR. COHN: Kepa.
DR. ZUBELDIA: I would like to maybe put this in context of the previous panel and in the previous panel we had some testimony that we don't need the patient's birth weight because we have been doing without it for so many years and it is not necessary. Maybe what we are hearing now is not as much as to whether the NDC is a good solution or not, but as why are we changing the practice for billing of using the J Code? We have been using the J Code for years for billing. Why all of the sudden we have to use the NDC code? If a HIPAA claim is strictly for billing, there may be advantages to using the NDC for billing errors and reporting other things, but if it is for billing, why are we switching away from the J Code, which is what we have been using all along. I think that is what I am hearing.
It is not that they want to change the practice of using the NDC code into J Code. They want to stay with the J Code that we have been using all along. They don't want a change forced on them.
MR. ARGES: And, again -- This is George Arges -- and, again, there is only a limited number of drugs that are reported. It is not a whole litany of drugs that might be available. So, keep that in mind when you look at even the future in terms of how it might apply to the business side of the transaction standards, the billing side.
DR. COHN: And, obviously, you are the transition man from the long term view. That is good. I guess the question gets to be this more what do we do in the near term and, obviously, we need to focus on that for the next half an hour, so that we can come up with some recommendations for the Secretary.
Now, one question I would have, speaking of the near term is, obviously, George, you have spoke about the institutional issue and specifically the hospital and the hospital outpatient. There is, I think, some question about how the physician provider and all of this ought to be handled. I saw, Betsy, in your document that there seemed to be some question about what ought to be used in that? Can you describe this physician claim?
MS. HUMPHREYS: Well, since it isn't my document, but, in fact, a large number of the people worked on it, I am not sure I can. I think the issue was just be sure in making any changes to this rule that we have now published the way we have published it, that we correctly understand the issues at all the different levels, that we are not, you know, fixing something for somebody and messing it up for somebody else. I think that based on the experience even of the people here today, who, obviously, are dealing with practice management software, as well as institutional software and comments such as those made by Clem and others, that it is safe to say that the NDC -- or it seems to be safe to say that the NDC code is not -- doesn't loom large in the life of the, you know, professional claim.
But we are still concerned. I heard very strongly, which seems perfectly obvious to me that if we are going to signal that this is going to be a change, the sooner we make the signal or we can legally do it, the better off we are. I think the concern in this is just making sure that we understood what the impact was everywhere.
DR. ZUBELDIA: Could I say we are not going to make a change. We are going to go back.
MS. HUMPHREYS: Unfortunately, we are not -- we would, therefore, ratify current practice, which I won't make any comment -- I just won't make any comment on that. But the fact is that what we do have here is that we have now a rule, which, unfortunately, does have to be changed.
DR. COHN: Dave Moertel, one of our panelists, wanted to make a comment. Dave, I am presuming that this is a clarification of the discussion?
MR. MOERTEL: Yes. Dave Moertel, again, from the Mayo Foundation.
My earlier testimony this morning included an Appendix C and it had to do with professional claims aspects of using the NDC code or not using the NDC codes and outlines in detail a number of the issues that will be faced by the physician practice and we can look at this as a HCFA 1500 type issue or a professional claim issue.
We have indicated about 10 or 12 -- 10 different issues that are very difficult. The professional environment as Kepa has indicated, at this point, I truly do not believe the NDC code is ready for prime time for the professional claim at all. As a matter of fact, these ten issues are very difficult for the professional practice to deal with at this point. I am very much in favor of Betsy's comment that sometime in the future when we are ready for prime time -- and I emphasize we are not today -- that we should look at that. There are very good reasons for having some more specific coding and, you know, the drug errors -- I don't have to say anything there. That pretty well speaks for itself. So, I do think we need to look to the future, but I also will tell you very dramatically that we have just been through a Y2K upgrade. We have just been through APCs. As a matter of fact, we are continuing to go through an upgrade for the APC process, as some of the errors and changes are being taken care of. To throw the NDC issue on top of all of that for the providers without sound reasons, I think, is unconscionable. I don't see a reason at this point that we should make this change.
I haven't heard from anybody outside of home health -- and I think Kepa has a very reasonable solution. If home health is bound and determined to have NDC codes in the 837, let's put it as a situational element and they can put it in the reference. That is fine, but don't put that on the rest of the providers and institutional groups. I think he has a very sound way to handle that particular issue, but I cannot find anywhere in the industry a professional office that is asking for the NDC code, a hospital that is asking for the NDC code, at least not from the groups that I have talked to.
I would love to listen to the explanation from the people that are looking for it. Right now, I would say that we hold with the current practice, which is using the J Code and when another system is ready for prime time, that is great. Let's look at it and let's see how it can improve -- how we handle this.
DR. COHN: Mark, I think you are next.
MR. MC LAUGHLIN: I do concur with everything that Dave just said as well. You will notice from my testimony that the largest number of hours spent is going to be on those clinical practice management systems and that is because they don't have that interaction with the hospital pharmacy systems to be able to obtain that code.
They have got to be able to decide how to turn one J Code into one of the many NDC codes. So, I think that the issue on the provider side or the practice management side is much more complex.
DR. COHN: Don.
MR. BECHTEL: I just thought I would join forces and agree.
DR. ZUBELDIA: I would like to mention that I have had extensive discussions with the Home Health Infusion Coalition on this issue and they believe that having the NDC codes in addition to a J Code would solve the problem. So, they have the J Code with the NDC code. That is what they need because for home health -- with the NDC code.
DR. MC DONALD: Is that really more like ambulatory -- is that more like community pharmacy? Is that what they are doing, sending it to pharmacy?
DR. ZUBELDIA: Abbott Laboratories is leading that effort.
DR. GREBERMAN: First a question and then a comment.
One is given the sentiment against the NDC for the purposes that we are now talking about, we have a little bit of -- maybe some of you can give a sense of how did it get there and maybe some of the reasons behind why it is in there, which might help us have some discussion. I guess, whatever solution we come up to in terms of addressing some of these issues, I really think they have to be in the context of the broader points that Mike made, rather than just one shot for that alone and forget about the broader issues. But the history first would be helpful.
DR. COHN: I am not sure we have time for the history unless Betsy wants to give a 30 second version.
MS. HUMPHREYS: I am going to let Karen do that.
MS. TRUDEL: It is in Betsy's background paper.
MS. HUMPHREYS: It is in the background paper. I think essentially there were some ideas, there were some things -- we basically do have two federal agencies assigning codes to the same drugs in succession, which on the face of it is not wonderful. We have all these people across the country creating their own local drug codes because they couldn't get them in HCPCS fast enough.
There are some aspects of this whole situation between the J Codes and the NDC codes, which are not lovely. I mean, by any analysis, you say what is going on here. But I think that that level of shall we say -- the level of duplication and the administrative problems that exist in the creation and maintenance of the two systems and so forth is one thing and it is there.
I think that in the original analysis there was a lot of weight given to that and that is not unreasonable, but I think that the clarify of information that came in later -- and there was good hints of this in the original comments. I am not going to say there wasn't, but these other factors were kind of leading the discussion of the people who were doing the analysis.
Then the much more specific and on target and more -- you know, fuller comments about what is the impact of this on the industry, which came in after really caused everyone within the Department who then was involved in the analysis and the discussion of this to say, hey, this may be a good thing for these reasons over here, but the impact of this -- and it is kind of like somebody says, the advantages are not outweighed in the short term by the impact on the industry. I think that the impact on the industry was just not fully understood. Although in the best of all possible worlds, we might have discovered that -- we just did and we didn't really focus on it until these comments came in.
So, I think that is probably the sum total of it.
DR. ZUBELDIA: I have a question for Karen. It seems like there is a building consensus that we should go back to a J Code short term until there is a better -- there is a good solution. In the meantime and in the context of this, is that something that could be included in the maintenance of national codes because the maintenance of national HCPC codes is going to be the expedited -- they don't have a representative here, but would they be ready to support maintenance of the J Codes in it?
All the states have their own local drug codes because they couldn't get an international code.
DR. COHN: Just to clarify, actually drug codes exist around all levels of HCPCS. I think you are asking about whether they do a good job. Maybe that is kind of a letter we need to send once we put everything together to HHS suggesting -- ask Karen about what we need to do.
MS. TRUDEL: I don't have an answer to that and the reason that I don't is that when the HCPCS group in HCFA made their assumptions as to whether they could handle, for instance, the elimination of local codes in a two year period, they were assuming that they were not going to have to bear the burden of drug codes anymore.
I think that is something that is an extremely good point and I need to go back and say, okay, now in addition to the burden that you already knew you were carrying, here is another one. How is that going to affect you and can you cope with it? So, I will need to take that question back.
MS. WEIKER: How about EDS views? I would agree with what has been said in regard to the institutional setting. However, as a processor one in four claims for every American in this country, we are seeing that there are instances where we are dealing in NDC codes and health plans are paying NDC codes on professional claims.
In some instances a dispensing physician will give you x number of pills in his office and a health plan will pay for that. There is some confusion in the industry for those health plans where the physicians continue to use the 837 to bill that or do they use the NCPDP standard but are they a retail pharmacy. And they would say "no," you are not a retail. So, then it has to be billed on an 837. So, therefore, the capability to bill NDC has to remain on that 837 professional claim.
DR. COHN: Okay. Well, thank you for increasing the complexity.
I was just going to ask as we continue this conversation are there any comments?
MS. WEIKER: There have been no comments posted at this time to the web site.
DR. ZUBELDIA: Would that be resolved with having the NDC code in the claim or do they also need to use maybe a not otherwise classified J Code, J9999 that says look in the right segment for the NDC code that corresponds to this and then pay me.
MS. WEIKER: That is one solution. I mean, you would have to put that in the guide. If you are a dispensing physician, you would have to put 999 here and an arrest segment, which isn't in the guide and I don't think data element 128 has a code value for NDC. That would also have to be added to the X12 standard. I mean, that is the solution. It just has to be put into the guide.
DR. COHN: George.
MR. ARGES: I just wanted to follow-up on the previous question that Kepa asked Karen and that is the maintenance of the HCPC J Codes. I was just asking over here who else besides HCFA is primarily the main user of this. I have been told many of the Medicaid agencies are also big users and a lot of them fall into these level 3 codes, which are local codes.
Obviously, you know, that process has already been laid out in terms of indicating that the level 3 codes need to be worked through the HCPC process. I just think that would also add additional benefit because you can standardize some of that from a national level than to have the local HCPC codes basically defined as though -- if you can put more time in people behind that aspect, I think it may eliminate a lot of the local use codes as well.
DR. COHN: Actually I am going to just take a minute here because I will apologize -- we actually have a new member of the full committee and this is his first attendance of the subcommittee meeting. I would like to welcome you and --it is Dr. Ted Shortliffe from Columbia. We want to thank you for joining us.
We have about ten more minutes to try to come up with our view of a recommendation. It will have to be approved at the NCVHS meeting later on this month. So, let's have a discussion and then let's think about what may need to be in that letter.
MR. LEVIN: I guess I just wanted to go back to this ingredient code and see what the interest is there. I mean, it sounds like that might be a way to go, a solution
-- not a solution, but a direction that we can go in.
DR. COHN: Jeff.
MR. BLAIR: Randy, I am really pleased to hear about this and I didn't get a chance to say "hello" to you at the HL7 meeting. You were there and I am so pleased that FDA is now participating in these standard development organizations.
To be honest with you, I think that the forum that happens to be going in there will -- in addition to whatever comments you receive here, will really help you to have an appreciation for the requirement for routes, strengths, doses, in addition to ingredients because a number of the vendors are active in that group. You have the drug knowledge-based vendors as well. You have a number of the terminology developers as well. That interaction -- so I would just simply would wind up saying that, you know, I hope that the FDA will continue to make itself present at those sessions. I think you could get a good deal of information from those groups.
DR. COHN: Dave Moertel has his hand up.
MR. MOERTEL: Just real short. You had asked about the information on the DSMO site. The only comment on the DSMO site up until now was for the institutional claim. Now there is a comment pertaining to the professional claim.
So, as far as comments on the professional side, there hasn't been an opportunity. That comment just went out yesterday. I just wanted to clarify that, that there are two pieces here; one for the institutional and one for the professional.
DR. COHN: Let me make sort of a thought here and sort of see what the members of the subcommittee feel about this. What I have been hearing is very much of a need to recommend to the Secretary that there be a change in the final rule to change the status quo in relationship to the use of HCPCS codes for drugs and biologics. We don't mean exactly in the status quo but we mean pretty close because when Kepa mentioned that we might want to have HCPCS in the main segment.
I think I am also hearing that we need to go back and sort of reaffirm that, obviously, more global, but more appropriately meets these needs that do need to be developed and this is sort of along the lines with our previous recommendations for a drug terminology and that we basically are reaffirming the need for that and we should be talking about the transition occurring at that point that here is something that has been tested and has been shown to be of greater value than the HCPCS codes.
Is that sort of what I am hearing from everybody? Jeff, are you nodding your head?
MR. BLAIR: I am sorry. I was getting an education here on some things that -- I didn't hear your question.
DR. COHN: What I was describing was effectively what we would communicate in the letter. Recommending to the Secretary along with moving towards development and testing of a new drug terminology and implementation at such time --
MR. BLAIR: I think we also want to bound -- our testifiers, I think -- excuse me -- I think our testifiers indicated the domain in which the J Codes or other HCPC drug codes are appropriate. I think we should bound our letter to what they referenced because NDC codes are helpful in other domains.
MS. FYFFE: Kathleen is nodding her head.
DR. COHN: Nodding on that piece also.
DR. GREBERMAN: I am nodding my head, too, but I think rather than just moving off to some undefined time in the sky that we will get to this better way, we might want to, at least, say we would like to have some additional discussion and specific proposals about some of these next options we might want to consider.
DR. COHN: Okay.
DR. MC DONALD: That is what I worry about. I agree a hundred percent with this. This is a major issue to the medical record component of what we are talking about. So, that is going to be number one, numero uno, and we have been waving that flag all along.
I just worry -- this is getting into a very tiny little thing that we are only allowed to do a little bit with; namely, to suggest modification right away, and I just worry that it may get -- I think we ought to either make a
-- this is a modification suggestion. You are going to have some other suggestions. I just worry it might screw up the suggestion we are trying to make.
MS. HUMPHREYS: Or you can send two letters.
DR. MC DONALD: That would be better.
DR. COHN: I think a final paragraph talking about the need for the development -- the need to do developed and piloted in such time as X. I guess we will have to make up the letters and -- this letter is not being written in secret and sent out to the Secretary. This letter will come back in an advanced draft. So, we will have a chance to review it in the meantime.
DR. ZUBELDIA: Can I wordsmith your last paragraph of the letter. Be sure to include the three uses that Michael has described. I think that is important to reflect there.
DR. COHN: Okay. Now, I guess I should ask our panelists -- first of all, I want to thank you for bringing the issue forward to the committee. Obviously, I think it is important that we identify issues and try to mitigate problems that we are all having with implementation. Of course, implementation is very important, which if done right will have great benefit to the healthcare industry. We just need to make sure that it is done right.
Have I described the issues that you have issues that you brought forward?
MR. ARGES: Yes.
DR. COHN: Okay. Great.
We want to thank you. It is now a couple minutes before 3:00 and we will adjourn for a 15 minute break and start at about 3:10. Thank you all.
[Brief recess.]
DR. COHN: Everyone be seated, please.
Our last panel today is on digital electronic signature. It is really a status report.
I actually want to thank Kepa Zubeldia for taking leadership in terms of moving the issues of digital/electronic signature forward. I think those of us who were at the last session, the last set of hearings, realize that this is an important issue to the healthcare industry and that there needs to be leadership taken by NCVHS to help move the process forward.
Even though the security and electronic signature standard came out as a notice of proposed rule -- so, our intent is to try to get this thing moving.
Kepa, would you like to make any comments now? Okay. Kepa will hold his comments for later.
With that, my understanding, even though I was not present, was that there was a meeting with the FDA in January to further discuss this issue. Obviously, we have asked them to come and share their views of the progress.
Glen Marshall, I think you represent HL7 and you are first up.
MR. MARSHALL: Yes, I am.
MR. BLAIR: Glen, for my benefit and for those on the Internet, could you speak into the microphone.
MR. MARSHALL: My name is Glen Marshall. I am speaking on behalf of Health Level Seven, an ANSI-accredited standards development organization, as a co-chair of its security and accountability special interest group.
Professionally, I am a healthcare systems architect employed by Siemens Health Services, formerly known as Shared Medical Systems. I have worked in healthcare IT for 34 years. My focus is on healthcare security and privacy systems.
Here are my responses to some questions that were provided at my invitation to testify today.
First, why is your SDO interested in electronic signatures at this time and what business processes will be enabled or improved by electronic signatures in the future?
Although the HIPAA transaction standards, including the proposed claims attachment standard, do not currently require electronic signatures, we believe that future transactions considered for adoption and the expansion of the scope of claims attachments will ultimately lead to such a requirement.
Electronic signatures will facilitate mutual authentication, data privacy, confidentiality, integrity and nonrepudiation. They will also enable a clear representation of the authority and intent of those accountable for the data.
We also believe that current cross-industry standards for electronic signatures do not meet these requirements for the healthcare community in general, while the healthcare-specific standards do not hold sufficient promise of being widely implemented.
Absent an electronic signature standard that meets healthcare requirements and can be widely implemented, any HIPAA rule would require trading partners to integrate one of a kind software and/or develop bilateral specifications that interpret the standard. This is contrary to the spirit of administrative simplification and would likely cause provider organizations to opt out of using the underlying transactions.
The current state of electronic signature standards and technology demands a proactive effort by SDOs to develop and deploy a comprehensive standard that can be implemented within the expected compliance time frame once regulations are published.
Second, what electronic signature standards are practically being used today, to what extent are they being implemented, and for what purpose, in connection with the standards developed by your SDO?
Today, electronic signatures are most typically used when establishing a secure connection over the Internet rather than in conjunction with any given messaging or transaction standard. That is, at least one of the computers in the connection possesses an X.509 digital certificate and uses a public/private key scheme to establish an encrypted connection.
This connection has the attributes of confidentiality and integrity. Data communicated over the channel is secured by a key known only to the connected machines such that any change to the data, whether accidental or intentional, produces a clearly invalid result upon decryption.
Third, what are the problems or limitations of your current electronic signature methods?
Today's secured connections lack the attribute of mutual authentication unless both endpoints of the connection possess a digital certificate. Because of this, they also lack the ability to assert nonrepudiation. Mutual authentication and nonrepudiation are important attributes for healthcare data.
Currently implemented standards only authenticate the computing device. They are unable to convey the credentialed authentications of end-users in a data exchange nor the intent, attestation, authority and accountability of the sender.
Some individual health information systems provide electronic signature capabilities that apply to data stored in their databases, but in the absence of implemented standards, the signatures are not represented in a manner that is persistent and portable and that provides the ability to detect subsequent alteration of the information that was putatively signed.
As stated in the NPRM, electronic signature standards that meet these requirements will certainly require the use of digital certificates. At the same time, they must handle the use case where the signer is a consumer who does not have a portable digital certificate.
Fourth, to what extent do you believe that a HIPAA standard for electronic signatures will benefit the healthcare industry? Do you believe a HIPAA standard for signatures is possible? How would you go about adopting such a standard?
Electronic signature technology can help substantially reduce the latencies and costs of manual and paper-based processes, both for the transmission and retention of information. The savings desired from HIPAA administrative simplification will not be attained without a systematic reduction of such latencies and costs. A standard for healthcare electronic signatures would support such a solution, assuming requirements for privacy, confidentiality, credentialed authentication, integrity, nonrepudiation, intent, authority and accountability.
A HIPAA standard for electronic signatures is quite possible, presuming cooperation among SDOs. This cooperation should start with an effort aimed at using existing standards, creating implementation guidelines and culminating in an interoperability pilot project among vendor participants. It is key to note here that existing standards may well suffice, and all that is needed are proofs of implementation and interoperability.
Representatives from HL7, ASTM, X12N, NCPDP and IETF EDIINT met on January 8, 2001, to initiate such an effort. We agreed to produce a consensus scope statement and work plan by March 31, which I will author.
Assuming positive results and learnings from this initial effort, we may expose a need to update the existing standards. This will require action by the SDOs who are responsible for the standards, using their own processes. A HIPAA electronic signature standard itself, referencing the resulting standards used in the interoperability pilot and any updates to them, can arise from this step.
Fifth, what will be the impact of adopting a standard under HIPAA that is different from the electronic signature methods you are using today? What will be the advantages and disadvantages? Will your SDO support such a standard?
As mentioned earlier, the impact of a HIPAA electronic signature standard will be to facilitate mutual authentication, data privacy, confidentiality, integrity and nonrepudiation, while representing the authority and intent of those accountable for the data. Today we can only achieve machine-to-machine confidentiality, authentication and integrity, which are not sufficient to the requirements of healthcare privacy and accountability.
The key disadvantages, perhaps better stated as challenges, are in the implementation. Current digital signature software does not support existing digital signature standards, either industry-wide or healthcare specific. We will require the active involvement of vendors in an interoperability pilot to demonstrate workable implementations that meet the healthcare requirements based on existing standards. Recruiting such vendor participation will be part of the work plan.
HL7 will support the outcome of joint SDO efforts toward a recommended HIPAA standard for electronic signatures. As co-chair of the HL7 special interest group responsible for security and accountability, I will be personally involved in that effort.
Sixth, how could your SDO work with other SDOs and with NIST in coming up with such a consensus electronic signature standard?
As noted above, a cooperative work effort was initiated on January 8. We will publish the scope statement and work plan by the end of March 2001. Although NIST was not a participant in the January 8 meeting, the were identified as a source of input to the effort. NIST participation will be considered as an element of the work plan.
Seventh, what do you estimate will be the time frame for development of a consensus electronic signature standard that could be adopted under HIPAA?
I estimate a completion date some 9 to 12 months from the publication of the work plan, assuming a sufficiently high level of effort from each participant. At the end of that time the implementation guides and any related updates to standards should be ready to be balloted. Actual adoption depends on the meeting schedule and standards approval processes of each SDO.
To the extent that HL7 would need to conduct a ballot for this process, it can do so over the web without the requirement for a face-to-face meeting, consistent with the policy of the American National Standards Institute. We balloted the implementation guide for HIPAA claims attachment in two months.
Eighth, what should be the role of the HISB and of NIST in developing such consensus standard?
I see HISB providing direct coordination of the multi-SDO project and NIST providing technical guidance on the robustness of the standard and coordination with other government electronic signature projects.
Ninth, what role would you like the NCVHS to play in this area?
NCVHS should review the work to ensure that the requirements of healthcare and HIPAA are represented in the various products of the project. Relative to just HIPAA, NCVHS needs to help advocate the adoption of an electronic signature standard.
DR. COHN: Thank you.
Mike Lundie.
MR. LUNDIE: Good afternoon, ladies and gentlemen, distinguished members of the committee. My name is Michael Lundie. I am the director of health industry marketing for Cyclone Commerce.
My background is in healthcare information technology, where I have held various positions, both technical and managerial for some 25 years. Accompanying me here today is Mr. Paul Bussey, security components development manager for Cyclone Commerce. We thank you for the invitation to speak with you today on the use of electronic signatures within healthcare.
Cyclone Commerce, a privately held corporation headquartered in Scottsdale, Arizona, is the premier provider of Trading Community Management software utilized in successful B2B implementations utilizing the Internet. As such, Cyclone's Interchange software is installed in some 300 clients throughout the world in various industries, including nearly 60 healthcare related entities.
Companies such as Begen Brunswig, McKessonHBOC, St. Joseph's Health System, ExpressBill, a division of WebMD, Glaxo-SmithKline, and most recently the New Health Exchange, utilize our software as a way of providing secure data transport and scalable community management over the Internet.
Our software supports various forms of data transport, one of them being a B2B framework known as EDIINT. It is with this group that I serve as a liaison between the various healthcare SDOs to ensure the needs of the healthcare industry are represented within the EDIINT task force. And it is the interests of the EDIINT task force that I represent here today.
As to Question 1, why is your SDO interested in electronic signatures at this time and what business processes will be enabled or improved by electronic signatures in the future, the IETF or Internet Engineering Task Force, the parent SDO, commissioned the EDIINT task force with creating a standard for sending EDI data securely over the Internet. Early on, this group realized that a general approach would allow any payload, not just EDI, to be sent securely over the Internet.
The EDIINT standard created and currently supported by over a dozen vendors defines a method for encrypting, signing and transporting any data payload over the Internet.
EDIINT, an existing standard, with hundreds of implementations, can be leveraged, and is being utilized by the healthcare community to securely transport any healthcare information over the Internet. The signatures currently used by EDIINT are corporate signatures, which ensure one corporation that a document received via the Internet came from a specific trading partner.
We believe that security concepts developed for use with EDIINT may be leveraged to provide a level of support for personal signatures required by HIPAA. The EDIINT task force intends to work with the SDOs within the healthcare community to create an end-to-end solution that meets their specific needs.
As to Question 2, what electronic signature standards are practically being used today, to what extent are they being implemented, and for what purpose, in connection with the standards developed by your SDO, EDIINT uses X.509 certificates. Although the standard permits PGP/MIME and encourages the use of certificate authorities, most of the installations use S/MIME as a packaging standard and allow self-signed certificates. In other words, companies who already trust each other exchange public keys by trading X.509 certificates.
As to Question 3, what are the problems or limitations of your current electronic signature methods, relative to the needs of healthcare, the only limitation of EDIINT is direct support of personal signatures is not provided. But this is an artifact of what EDIINT is sued for rather than a technical limitation.
EDIINT is built on top of the well-known PKI concepts. The theory behind the technology is considered to be sound and when coupled with a CA, rather than a web of trust, trust model, is infinitely scalable.
Question 4, to what extent do you believe that a HIPAA standard for electronic signatures will benefit the healthcare industry? Do you believe a HIPAA standard for signatures is possible? How would you go about adopting such a standard?
I suspect that the most immediate advantage of HIPAA may be the ability to leverage the Internet to securely transfer healthcare documents. A HIPAA standard for signatures is possible. I believe that a generic signature standard already exists.
The existing problem is not one of inventing a reliable signature but identifying, then defining an implementation for each signature use case. The ASTM identified the use cases, Standard Guide on Security Framework for Healthcare Information: E2085-0, but work still needs to be done on a standard for implementation of each use case.
It is not clear that EDIINT will have a direct role in defining these use case implementation standards but we do stand ready to make any modifications necessary to EDIINT to ensure the payloads defined by the healthcare SDOs can be transmitted via EDIINT.
Fifth, what will be the impact of adopting a standard under HIPAA that is different from the electronic signature methods you are using today? What will be the advantages and disadvantages? Will your SDO support such a standard?
EDIINT supports digital signatures created by signing an electronic document with a private key. Certain algorithms are explicitly supported but none are disallowed. But vendors have not elected to support all standards. All interoperability trials used RSA as the signing algorithm. EDIINT is not opposed to other signature algorithms but the disadvantages of using something besides RSA is simply the amount of vendor support.
I might add that RSA was chosen even when it was covered by patent. This is no longer the case.
How could your SDO work with other SDOs and with NIST in coming up with such a consensus electronic signature standard?
EDIINT is more of a secure transport standard. The signatures specified are at the corporate level. However, we are already working with the healthcare SDOs to ensure that the EDIINT standard will support whatever payload is defined to support the personal signatures, i.e., doctor, patient, affixed to the payload which needs to be transferred by EDIINT.
In addition, members of EDIINT who have security expertise are already working with the healthcare SDOs to define standards for each signature use case.
What do you estimate will be the time frame for development of a consensus electronic signature standard that could be adopted under HIPAA?
Defining an algorithm should not take long. Since there are several completely acceptable technical approaches, making a decision is more important than the decision made. The bigger effort is defining an implementation for each signature use case. This effort could easily take five to ten months for a committee to complete. Fortunately, a significant portion of the effort clearly defining the signature use cases has been completed by ASTM.
It seems to me that each of these use cases will take a chunk of time and a phased deliverable could be defined where the most important or most common use cases could be defined first. EDIINT is in no position to make priority judgments in this area.
What should be the role of HISB and of NIST in developing such consensus standard?
EDIINT was very recently invited by the healthcare SDOs to assist in meeting HIPAA requirements in a timely manner. My impression is that these SDOs are currently working well together to respond to the HIPAA requirements.
I think the best role for HISB or NIST to play is to set specific and aggressive targets for delivering a specification. These should include, when possible, milestone targets which occur every few months. My rational is this: The question is not whether the technology is up to the task but in choosing what technology or combination of technologies to use.
When presented with many viable options, a task has a tendency to expand to meet the time allocated. This is especially true of committee work. My strong suspicion is the technical advantages of one approach over another are not as important as specifying a viable solution and moving forward.
As to Question 9, I would offer the same answer.
Thank you.
DR. COHN: Mike, thank you very much.
Jan Lovorn.
MS. LOVORN: This time I have my voice. Last time I was here, as you know, I croaked my way through it.
I actually have it, but I didn't get a chance to get it printed out. So, I will be providing to the committee via e-mail.
My name is Jan Lovorn and I am the chief privacy officer for a company called Protegrity and I am past chair of ASTM subcommittee that actually wrote these standards that they have been talking about. It was my greatest pleasure to be involved in the development process.
To give you an idea, we have developed four primary standards in response to the original HIPAA legislation back in 1997 in 15 months time. So, this is a doable effort in much less time.
First, let me thank the committee for this opportunity to speak to you again today. As I have testified before, the committee became aware of the security requirement in the mid 1990s. Work began under the auspices of Peter Waegermann of MRI on the requirement statute to authenticate health information as early as 1994.
The standard guide on the authentication of healthcare information was published in 1995. It came up for revision last year and there was not substantial things, other than to update some of the references that were performed on that particular standard.
In fact, the criteria that are identified in that document were also the ones that were listed in the draft NPRM on security for digital signature or the requirements under that, are some of the things that were extracted from that document.
We developed the standards as a result of HIPAA and ongoing work for the Kennedy-Kassebaum bill that was actually the precursor to HIPAA and also the recurring and increasing need to protect health information. Our committee is not just driven by the requirements of the regulatory environment, but it is also driven by what our users and participants need to help them in the way of doing their everyday business.
The committee was composed and is composed of healthcare providers, healthcare organizations, computer security implementers and many other people interested in the protection of healthcare information. Two additional standards for development that apply to digital signatures, are technical security framework. That is ASTD2085.
I am sorry. The members have just been recently assigned. So, I haven't quite got them rolling off my lips yet. The digital signature guideline that we have also discussed, which is also E2084.
It is interesting, when I was doing some research for this to find out that I found my presentation I made to the committee in August of 1997. There is not substantial differences between what we were doing then and what we have done now, which I think that ASTM needs to be recognized for because the standards have stood up to the time and people have implemented it.
The first question: Why is your interest in electronic signatures at this time? Well, ASTM early on saw that requirements in the healthcare industry for a method to provide authentication of healthcare information, as well as a method for data integrity and data nonrepudiation of actions on that information. Based on the criteria defined in E1762, that is the guide for authentication, electronic authentication of health care information, the existing research was found to be the only technology that currently meets those requirements.
We invited other vendors to put up other kinds of electronic signatures against the requirements. None of them were willing to do that because they didn't meet the requirements. So, right now, the requirements that are identified in E1762 are only met by digital signature technology. So, those two standards were developed.
What electronic signature standards are practically being used today, to what extent are they being implemented and for what purpose in connection with the standards implemented and developed by your SDO?
ASTME2084 is based on security industry standards developed by ANSI and by INSEL(?) and by NIST. Following, I am give you some of the standards that we used. Of course, we used ASTM, E1762. We used ANSI X9.30 on using algorithms. Again, the RSA, X9.31 and the elliptical curves, which is a new technology for doing digital signatures. It has much smaller key lengths if you need to have that because you don't have large processing capability.
There is ISO standards 9796 and 9594 that deal with authentication and with digital signature. There is also an RFC that was used on basing the digital signature one on cryptographic message syntax. So, what I would like to say is that ASTM worked with the ongoing standards developing Internet he information security arena to develop these standards.
We did not go out and reinvent a standard or standards that totally redefined what was going on in information security. We only identified those parameters in our standards that needed to be addressed to solve the requirements of health care and set up those parameters and defined minimum standards for those.
One of the problems or limitations in the current electronic signature methods, none that we have been told about, key length may need to be increased due to the advances in technology and processing power since this was originally written three and a half years ago. But several implementations, mainly requirements of the ANSI and ISO standards, have been available in the stall for several years in other markets.
The implementation should be verified against the ASTM standards, but the committee sees no problems due to the diligence that the subcommittee used to follow their existing standards. So, there may need to be minor changes as a result of this common SDO effort, but they are in concert with what is going on in the information security the way it is right now.
To what extent do you believe that a HIPAA standard for electronic signatures will benefit the healthcare industry? Do you believe that a HIPAA standard for signatures is possible? How would you go about adopting such a standard?
A little tongue in cheek, but not entirely, ASTM Committee E31 feels that we have developed a standard of digital signatures that can be used by HIPAA implementers to meet the requirements identified in the security NPRM and in privacy final regulations. Some of those requirements were taken from E1762 for electronic signatures. Only digital signatures meet all the requirements identified in E1762 and in the security NPRM.
What will be the impact of adopting a standard under HIPAA that is different from the electronic signature methods you are using today? What will be the advantages and disadvantages and will your SDO support such a standard?
If there are significant differences in a HIPAA standard from what is going on in the information industry, that could have significant impact on the other markets and on the vendors that provide information security at this point.
But in conjunction with having administrative simplification, if we can use some of the things that are going on in other industries and require minimal changes, that makes for less costly implementation.
How could your SDO work with other SDOs and with NIST in coming up with such a consensus electronic signature standard?
ASTM would be happy to work with the SDOs and, in fact, we did participate in the meeting in January down in Orlando to develop additional standards or implementation guides for digital signature. In addition to technical standards as developed by E3120, which is the Subcommittee on Data and System Security for Health Information, with a sister subcommittee, E3117, on privacy, confidentiality and access that focuses on the policy part of this that would also be actively involved in this effort.
We would attend the joint development meetings, work on the joint products and review all the standards before publishing to determine that they meet the relevant ASTM standards and the industry standard. To meet consensus, ASTM may need to revise existing standards and is willing to do so. Our goal is to develop usable standards that meet the ongoing requirements of the healthcare industry.
What do you estimate will be the time frame?
Well, I said if we started from scratch, it could take 18 months. That is normally the standards development organization. But if there is already a foundation document that has been developed in the E1762, E2084 and E2085, I think that can be cut down to less than a year's time. We may be able to have individual ones of them implemented in six months from the date that Glen was talking about, the end of March.
I think this is doable in a real positive time frame because other industries are doing this as we speak. Health care is not the only one that is looking at these implementations or has to have these implementations. So, it is not totally reinventing the wheel here. We are building on other foundations and other experiences and other marketplaces.
What would be the role of HISB and of NIST in developing such a consensus standard?
ANSI has begun to provide the coordination of the SDOs and the development of the implementation guides that were identified in the January 8th meeting. NIST is no longer in the standards development process for information security. It participates in ANSI X9, IEEE and IEPS in the development of such standards. While it is still doing some, primarily its mandate has been to oversee this development in the marketplace rather than as a separate government entity.
Even with the new advanced encryption standard that was just announced last fall, the final document will probably be handled and be coming out as an ANSI standard rather than a NIST publication. It probably will come out as both but a lot more of the detail will be handled in ANSI.
What role would you like the NCVHS to play in this area?
I agree with Mike and what he said, becoming an advocate for this in the industry and we also need you to provide the encouragement and the additional guidelines so that the SDOs can get together to meet the needs of the healthcare industry.
Thank you.
I have also out of fairness provided -- I know that ASTM has provided its statements to the committee and that I have attached to this or also to my presentation that I did in January down in Florida.
Thank you.
DR. COHN: Okay, Jan. Thank you very much.
Dan Staniec.
MR. STANIEC: I would like to thank you for the opportunity to testify this afternoon to discuss the status of digital/electronic signatures in the pharmacy services sector of the healthcare industry. My name is Dan Staniec, the National Council for Prescription Drug Programs, executive vice president of business development and external affairs.
As you know, NCPDP is a 1,300 member, ANSI accredited standards development organization in the pharmacy services sector of the healthcare industry. NCPDP's Work Group Twelve, which is called Data Security and Patient Confidentiality, has taken n the responsibility of working on the topic of electronic signatures. This work group has created a smaller task group to evaluate not only the electronic signatures/digital certificates being used in retail pharmacy today, but to evaluate the other standards development organizations' standards and see if they make business sense for our members.
NCPDP had a representative, Margaret Weiker, who attended the multi-SDO digital signature meeting on January 8, 2001 in Orlando, Florida. Margaret is one of the NCPDP standardization co-chairs and she is also a PCPDP board of trustees member. As you recall, Margaret did testify earlier this morning. NCPDP has made a commitment t work together with all the SDOs to cooperatively agree on a work product that benefits everyone in health care.
Here are NCPDP's responses to your nine questions presented to us earlier.
Question No. 1: Why is your SDO interested in electronic signatures at this time and what business processes will be enabled or improved by electronic signatures in the future?
NCPDP has been instrumental in the development of electronic prescriptions over the past several years. NCPDP has an ANSI accredited standard called SCRIPT that is an electronic prescriber/pharmacist interface standard used for transmitting electronic prescriptions. Also, it is important to note that NCPDP has a telecommunication claim standard 5.1, which was mentioned in the HIPAA final rule on transaction code sets. Only the SCRIPT standard would be directly affected in the near term by digital signature legislation.
Even though NCPDP developed SCRIPT, the rules and regulations governing the usage of the standard is governed by state laws. The individual state boards of pharmacy vary as to whether they allow electronic prescribing or not. Some states do not allow electronic prescribing at all. Among those that do, few address electronic signatures.
By implementing digital signatures, additional states may be convinced to allow online prescription submission, furthering the goals of administrative simplification. On the pharmacy side of the prescriber/pharmacy transaction, one of the biggest challenges is authenticating a prescriber.
NCPDP is aware that the DEA is looking into this issue and has placed documents on their web site regarding their work on prescribing controlled substances that will require electronic signatures. This is exceptionally important to our constituents.
We are also interested in other potential use cases, such as prior authorization and medical necessity issues.
Question No. 2: What electronic signature standards are practically being used today, to what extent are they being implemented and for what purpose, in connection with the standards developed by your SDO?
NCPDP does not have an electronic signature standard. A small number of our member companies, when allowed by state law, use a variety of identification and authentication methodologies for this business function.
Question No. 3: What are the problems or limitations of your current electronic signature methods?
The United States healthcare industry today does not have one electronic signature standard. There are a number of electronic signature standards available today for certain business needs.
There seems to be widespread confusion over what constitutes an electronic signature. On the Internet, digital certificates is emerging as the answer. However, most of our constituents use more secure value added networks or dedicated telephone lines instead of the Internet, and prescriber/pharmacist transactions are often transmitted via fax. Via these channels, some companies are arguing that digitized images of a physician's signature or codified identifiers constitute a physician's signature or codified identifiers constitute a physician's signature and some state boards of pharmacy have agreed. This needs clarification.
As it pertains to digital certificates, there are a number of companies that offer digital certificates, which complicates the issue even further. Will pharmacists be required to have more than one electronic signature, as well as pharmacy technicians? If a pharmacist works in different settings, i.e., hospital versus retail, will he need multiple digital certificates? Will a physician need more than one, if he/she practices in multiple settings?
Who will act as certificate authority? We are concerned about future regulations that require such certificates and the burden that they would impose. NCPDP will be discussing these issues in detail at our work group meetings and also the joint SDO meetings.
Question No. 4: To what extent do you believe that a HIPAA standard for electronic signatures will benefit the health care industry? Do you believe a HIPAA standard for signatures is possible? How would you go about adopting such a standard?
A HIPAA standard for electronic signatures would benefit the healthcare industry by mandating a federal law, ne standard to be used by everyone, versus the multiple standards in use today. Over the long term, costs would be reduced with only one implementation to follow.
A HIPAA standard for signatures is possible, but other issues need to be addressed for this business functionality to succeed. Interoperability issues must be addressed and solved, otherwise a HIPAA mandated electronic signature standard would not work. The WEDI AFEHCT interoperability project did have some challenges with interoperability and we can learn from their experiences as we move forward to resolve this issue.
NCPDP is concerned with multiple certificate authorities. What happens when you have multiple pharmacists and technicians in the pharmacy? How will pharmacies verify physicians that are at different sites? How many negative files will be stored and where? The certificate authority issue needs to be addressed at the same time as the electronic signature standard issue.
Question No. 5: What will be the impact of adopting a standard under HIPAA that is different from the electronic signature methods you are using today? What will be the advantages and disadvantages? Will your SDO support such a standard?
As you know, there is no one electronic signature standard today in the healthcare marketplace. NCPDP members will have to make modifications that will increase costs initially, such as machinery, software enhancements, digital certificates, et cetera. For example, what is the cost of obtaining a digital certificate and who will pay for it?
However, we do agree that adopting one standard will be cost effective over the long term. Another advantage is that one signature would eliminate the need to deal with the plethora of formats that currently exist today. As I mentioned earlier, NCPDP will work with the other SDOs to help solve the certificate authority and other interoperability issues.
Regarding disadvantages, there will be some up front costs that pharmacy will have to deal with, programming, purchase of machinery and staff training. Also, there are more transport methods used today besides just the Internet. These would have to be taken into consideration. In addition, not all pharmacies have Internet access.
Yes, NCPDP would support such a standard, as long as the standard met the business and technical needs of the pharmacy services sector of the healthcare industry.
Question No. 6: How could your SDO work with other SDOs and with NIST in coming up with such a consensus electronic signature standard?
As mentioned earlier, NCPDP has agreed to participate with the Multi-SDO Digital Signature Project. I will be the primary contact for NCPDP on this project. I agree to participate, along with NCPDP members, on joint meetings between the SDOs, conference calls and e-mails. As I mentioned earlier, we may also learn from the issues experienced during the WEDI AFECHT interoperability project.
Question No. 7: What do you estimate will be the time frame for development of consensus electronic signature standard that could be adopted under HIPAA?
Glen Marshall from HL7 will be creating a project plan document by March 31, 2001. As you have heard earlier, Glen Marshall has agreed to lead this Multi-SDO Digital Signature Project. After the project plan document is created and reviewed, the implementation guides will need to be created. These guides need to comply with past HIPAA regulations. We are anticipating time frames for this development to be included in the project plan document.
Other factors that will affect the time frame for development include the costs of implementing the standard. For example, software for encryption scanners will be needed in retail pharmacies. These devices and other software enhancements must be integrated in the existing pharmacy practice management systems. Also, the costs for storage of the scanned material must be addressed.
HL7 has agreed to fund this project. NCPDP has agreed to help with costs by offering conference calls with the other SDOs in a round robin fashion. Regarding implementation cost issues, the private healthcare industry has the burden of paying for all of this. We would like to ask if federal funding could help pay for implementing this standard. Another suggestion is that the certificate authority companies to possibly come up with funding.
Question No. 8: What should be the role of the HISB and/or NIST in developing such a consensus standard?
HISB does not develop standards in the healthcare industry and NIST does provide security standards for the Federal Government. NCPDP welcomes their members to join the multiple SDO digital signature group. We appreciate any feedback from them on these issues.
Question No. 9: What role would you like the NCVHS to play in this area?
NCPDP would like to ask the NCVHS to work with all of the SDOs and help monitor the process as we move forward with this project. As you know, standards development does take time in order to reach consensus, not only with our member companies, but also with other SDOs. We would like to ask for the necessary time for consensus on this standard versus putting one out there that will have problems and high costs.
We would appreciate any guidance regarding federal preemption. As you have heard earlier, state laws via the state board of pharmacies dictate the rules and regulations of NCPDP standards. Also, interstate commerce direction would be appreciated.
I want to thank you again for allowing me to share NCPDP's comments on these issues and I look forward to responding to other questions that you may have.
DR. COHN: Dan, thank you very much.
Gary Beatty, I guess, is not here. Was there a representative from X12 who was going to be testifying? Okay.
Peter Waegemann.
MR. WAEGEMANN: Thank you very much for inviting me. I did not get the questions in advance. So, I have the advantage of being able to respond to what has been said so far.
As you know, I mentioned it for the last testimony that I believe that claim standards in health care is one of the priorities and has the benefits. We really have two different issues and it is almost the same as what we had with the last panel and the panel before. We have a short term issue and a long term issue.
The short term issue is twofold. One part is should we recommend for HIPAA electronic signatures or digital signatures. Filling in, we really should have a discussion on what are the benefits, what are the disadvantages. On the one hand, I hear people saying how can someone today in the United States at a volume of over a trillion dollars send out claims, which are not authenticated.
To an outsider, this would be impossible. We don't know the amount of fraud being done. We don't know any other industry, which would allow it where the invoices are being sent out without a signature or someone saying this is what I really mean. This is from one side.
I hear on the other side that people are saying, well, we have been doing it so far without signatures and we are not aware of any fraud. Maybe we cannot prove any fraud and maybe we should just go on without having to spend substantial money to do a whole signature system. These are the two sides we have there and it is sort of right to put them on the table and try to come to some solution that way.
That is a short term issue we have. At the same time, we have now certainly with the request from HL7 -- and I am very pleased with that -- when I chaired the ASTM Subcommittee E3120 in 1994 and 1995 to create the basic standard at that time, everyone would tell me, Peter, the time for signatures hasn't come yet. Maybe it has come.
So, I am very pleased to see that some people are starting to look into that. We have been from ASTM for years trying to get individual people involved in it. What we have to realize here are two issues. One is the signature system is not as simple as some people here have indicated and as some people think. If you look at the standards work right now, what we really have to focus on is the international standards work.
A PKI standard and signature standard is created right now in ISO TC to 1.5. I can assure that most of it is based on the ASTM standards and most of the input comes from the United States. But I am mentioning this only for one reason.
This document where currently some 30 countries of the world create 20 signature systems for health care has a background paper on references and it is 17 pages of single-lined standards in the world on security and confidentiality in health care affecting signatures, 17 pages. So, as long as we realize that the standard 1762 and other ASTM standards are the tip of the iceberg, standing on many general signature, e-commerce signature and at the same time security standards.
So, what we have to realize here is when we talk about that, then there seems to be right now an SDO need to go into this. We need to look at coordination. That is why I am here. It is not that easy. What has been created in ASTM, the intellectual property rights were added three and a half years ago, where we had some problems between NCPDP and X12. NCPDP is using in some areas the X12 and they ended up to do standards work within X12.
What we have right now is with HL7, invited people and said you come to us and the same as NCPDP, where they have said you used X12 and you come to NCPDP. We need to work out on some of these issues how can we coordinate that. How can we address these issues?
ANSI HISB has its next meeting on April 7th -- March 7th -- and you have a press release in front of you. We have dedicated time there and we will start a process how we can work on these issues. It won't be easy, but I am very confident that it can be addressed and can be resolved as time goes on.
What we need to look at here is the following. First of all, Question No. 1 is how is a healthcare signature different from an e-commerce electronic signature or a digital signature? This is an issue, as Jan can probably confirm, that we started in 1994 and 1995 and spent many, many days and days discussing that. At this point, the International Medical Infomatics Community has had a consensus that a healthcare signature is different than an e-commerce signature and as different requirements.
And 1762 and 2085 and 2084 are the basis for that. That is No. 1.
No. 2 is that we really need to stay away from specifying an algorithm, from specifying any specific way of technology, which can be changed in two or three years. So, what we have to realize is we need some different ways here and probably what I would forecast -- and I could be wrong
-- is the first vision of how this works is that we need taking the current standards work and work on an implementation guide, one maybe for HL7 and maybe one for X12, which could include HIPAA transactions and use specific implementation guides with the input of the security experts of ASTM, but within the framework of each one of the syntaxes and the communication, which then applies, of course, to NCPDP.
This will take care of the short term issues. It will be quick and dirty because it will not be a full digital signature of PKI. We are kidding ourselves if we think that we just can pass out the private keys and public keys and we have a whole good signature system. You really need to look at the whole PKI with registration authorities, with cross authorities and so on and so on.
This will take some time. It is a long term project and I am confident as we are starting on the short term project that we will move into this long term project, which cannot be done in three months or six months. It may take a year.
We at HISB are currently coordinating also some of the PKI efforts. We have identified at this point 12 in the United States. There are at least an additional 20 or 30 worldwide in the healthcare field only. What we need is that Kaiser Permanente can accept some signature from London, England or from someone else in this country or from Tokyo and so on. So, we need to have a framework of acceptable ways for PKI and digital signatures. This is very complex.
We would be kidding ourselves if we think we can do this quickly. So, what I am saying is PKI may take some time. Let's focus on coordination. ANSI HISB is not a writing standard by instructions from ANSI. NIST is not writing standards at this point, but HISB is willing and ready to coordinate and help to work between ASTM and NCPDP and X12 and HL7 and anyone else who wants to work on that to make the short term solution possible.
What we have to realize here is that we will have to build this fine line of international standards because it would be wrong if we create in HL7 or in NCPDP or anywhere a standard, which is acceptable for the United States but is not in line with standards work being done on the international basis. So, we need to make sure that this is being coordinated at the same time.
In regard to a time frame, I think if we pick the short term issue and start working. In fact, I agree with what Glen and Jan have said and Dan, that we can start working on this. HISB is starting that in March and we will see where we get.
Thank you very much.
DR. COHN: Peter, thank you very much.
Questions from the subcommittee? Kepa, would you like to make any comments or questions?
DR. ZUBELDIA: Yes. Thank you, everybody, for testifying and for the work you are putting into making this possible. The reason why we called you here and the intent of the entire process with the multi-SDO PKI signature coordination is to move this digital signature aspect forward.
I think that with the security proposed rules, it was included in there and other responses and the comment we got from the security proposed rules that we can prove that there is not really a standard and it was kind of getting into a lead track. I hope that this is putting back in the right track and we will get something done quick.
But I am concerned by several of the things that I heard today and I am a little disturbed that X12 is not here because X12 didn't send a representative to Orlando either. That is disturbing. A lot of the standards we are talking about are X12 standards and X12 already has a standard, X12-58(?) for security of X12 standards that include the signature. I hope that you will make a special effort to work with X12 in this project because the last thing we would like to see is how the multi-SDO signature that does not include X12. I think that there needs to be a special outreach effort by the people in the room to X12.
Peter, I think you have a theory that I kind of fully agree with. But it is a little different from what some of the other people have said. You have talked about having one standard and having multiple implementations of that standard to satisfy different needs.
I think it was Glen Marshall that talked about having one standard with one implementation guide. I hope that I heard it wrong.
MR. MARSHALL: Kepa, in order to think of one implementation guide, that does not say that it is monolithic. I would expect that there would be multiple use cases expressed in such a document. So, consider it to be a series of guides in that respect.
DR. ZUBELDIA: Thank you.
In your interoperability pilot that you are going to have, you will be testing all those different implementations for satisfaction of all the ASTM requirements and all the SDO requirements. Is that --
MR. MARSHALL: I believe in an interoperability pilot and I am speaking off the cuff when I say this because the design work hasn't been done, but in my mind, an interoperability pilot would consist of a matrix showing who speaks to whom for what use cases. So, it is a three dimensional case.
Such an interoperability pilot was done with the EDIINT by Wade Croman(?) and Company awhile ago. So, we already have a template if you want to savor such an effort.
DR. ZUBELDIA: Okay. From what I heard, HL7 doesn't have one standard for health care. NCPDP doesn't have one standard for healthcare signatures -- sorry -- for signatures. And ASTM does have one standard for healthcare signatures. Is it the intention of the other SDOs to adopt the ASTM signature standard and express it in a manner that will satisfy your SDO needs?
MR. MARSHALL: We have reading the E1762 -- this is for HL7 -- E1762 and E2084, taken together --
MR. MOERTEL: They have been expanding a great deal of effort to put forth a framework that will be workable for the healthcare community. Have they been engaged, is my question?
MR. WAEGEMANN: The answer is "yes." They are one of the 12 organizations we are talking to in HISB and I would say that it is one of the 12.
MR. MOERTEL: Thank you.
DR. COHN: Mike.
DR. FITZMAURICE: Like Kepa, I, too, appreciate the work and the effort that you are going through to make something good happen.
I want to ask Peter for a clarification. First of all, you mentioned the HISB meeting on March the 6th. Is that meeting also on the 6th and the 7th? The reason I ask is that AHRQ sponsors that meeting and I think we have supported both days.
MR. WAEGEMANN: Thank you very much and I am most grateful for your agency to sponsor it. The HISB meeting is on March 6th and 7th. On the 6th we are dealing with many additional issues, particularly also XML coordination, also PKI might come up on the 6th, but the 7th, most of the time on the 7th will be for signature coordination.
MS. LOVORN: And on March the 5th is the U.S. TAG(?) meeting for ISO-02C215 and there will be discussion of the PKI documents that were presented in Stockholm in December and will be presented in Seoul in March for adoption as an international standard.
MR. WAEGEMANN: Thank you, Jan.
I should say the importance of a TAG is quite often overlooked. At that meeting, as well as other TAG meetings, we vote on a U.S. position on signatures and on PKI and cannot be reversed. We have one vote and at these meetings, for anyone who is interested in that, I only can encourage you to be there because that is where we come up with a national consensus.
I can see that in a couple of years people will say how did we get to the standard and we will say, well, we mentioned it then. TAG meetings are now going on.
DR. FITZMAURICE: I wanted to follow-up or to continue. In discussions with Peter in the past several years, I have become aware -- it has been impressed on me that there are unique requirements for health care that aren't met in any other commercial digital signatures. Yet, I want to ask the panel are there any other commercial digital signatures that come close to meeting the needs of health care or is that something you are looking at now?
MS. LOVORN: ASTM has looked at that and, yes, there are some differing requirements, but they are very similar. It is just the context of how you define some of the roles and some of the purposes. And fortunately, the structures that have been identified are expandable or changeable, configurable or selectable, so that you don't change the basic structure. You just set it up for which particular environment that you are in.
In part of the infrastructure can meet requirements in more than just the healthcare market, but there may be specific additional information that is applicable for health care.
MR. MARSHALL: I will have to take off my HL7 hat to really respond to this question and speak as a SMS or now Siemen's employee. With over a half million desktops involved, I am brutally aware of the scalability issues associated with this. I am not aware of any current commercial implementation that provides a level of interoperability, portability and scalability to meet just the business needs in cases that we represent.
I have spent a number of years on this and I have searched in vain for such a thing. I will tell you honestly I don't want to have to implement such a thing. I am looking for getting a vendor, if you will, otherwise interested in it. So that we find ourselves with a set of standards, which right now are paper documents that do not enjoy a scalable and robust implementation to the degree that I believe that we need for business, for the business I am in.
So, you know, I do admit not only as a standards developer, but also as a implementer certain interest in getting this work done because I feel it is necessary for the healthcare IT industry.
MS. LOVORN: The structure is still similar. It is just the different components that may have to be implemented are different.
DR. ZUBELDIA: What you said is extremely disturbing. What is your advice to us? Let me put it a little context around that. We could recommend to the Secretary to adopt this paper standard that has been put together by the multi-SDO. But it could be the wrong paper standard. It could be that by the time it gets implemented, it is completely out of sync with technology and with everything else.
Should we instead have some other mechanism, other than a HIPAA standard that gets put out to the industry as a target to shoot at and then when there is something more solidified, adopt it as a HIPAA standard?
MR. MARSHALL: My advice is that it should be within the HIPAA standard because that is really driving a large number of industry decisions right now. That is more a political statement than a technical one to be honest.
Frankly, we need to light a fire under the industry to get the work done. I believe that the necessary structures exist to do this work. It is not like it can't be done. It is a matter of moving the paper forward. Keep in mind that the proposal that is before this -- and in my comments, we did mention the need for an interoperability pilot.
I expect to be able to recruit vendors, who ultimately will produce the necessary commercial components for the industry and as a matter of fact, I have done some informal polling of people that I know of in the industry and there is quite a large amount of interest in pursuing this work.
MS. LOVORN: I think it also goes back to what Peter Waegermann said, which is what is our short term goal and what is our long term goal.
Digital signatures can be implemented without an infrastructure. Okay? Let's make it real clear about that. It is ongoing today. It is being done across the Internet. You can have a simplistic solution. If we want a full-blown implementation, it is a different story.
All these components will need to be made to work together, but this is the same thing about having the different MIME implementations that they have had around and different implementations in them. It took awhile to work a few of the bugs out. That is how technology moves forward. I don't think it should stop what health care needs and requires to support the electronic exchange of information.
Let's look at the short term solution, which is looking at what you need to get the actual digital signatures and then continue the work on looking at the infrastructure to support that in a global type of environment. That is ongoing right now in -- like Peter said, in TC215. So, NCVHS needs to be having someone follow what is going on in that environment and in some of the others for the PKI, which supports -- that is the public key infrastructure for those of you who don't know -- but the thing is is that that should not stop in my opinion, in ASTM's opinion, the ongoing work in actually implementing digital signatures, electronic signatures on health information.
MR. WAEGEMANN: I wanted to provoke you all and say something, which I probably will regret for the next couple of years, but I say it anyway as a response to Kepa.
What really is outdated that people would tell me that HIPAA is one of the most outdated technologies. We are basing everything we are doing on an EDI standard from 1994, where e-commerce is much more elegant, much more commercial, much better solutions today.
So, all I am saying is technology is going on and we may have to use what we do --
DR. ZUBELDIA: You will regret that.
MR. WAEGEMANN: I didn't say it. Someone else is saying it, just to put another perspective forward. So all of this is moving along.
DR. COHN: I actually wanted to follow up with your question, Kepa, about -- actually it is sort of directed more towards Mike. The sense I had of your testimony was is that you didn't think that everything was so dissimilar that health care was such a unique child that nothing else could ever -- nothing could potentially fit. I am curious, as you are listening to everybody saying no, no, health care is so different, et cetera, et cetera, could you perhaps give us some --
MR. LUNDIE: At the risk of -- you know, I am a technologist at heart so everything is solvable, given time and money, right? I don't want to oversimplify the issue and certainly the points these folks bring up are -- they are extremely complicated and I agree that there are long term issues associated with certificate practices and the legal implications behind them and the certificate authorities and how -- you know, what is the intent behind the digital signature? Those are all problems that need to be addressed and dealt with.
My particular framework as it exists with EDIINT and the company that I work for, Cyclone Commerce, is dedicated towards interoperability between multiple entities. We do it very well in commercial applications dealing with procurement, e-commerce kinds of initiatives. We do it day in and day out, as Jan had mentioned earlier. It works well with self-signed certificates, where there maybe isn't a certificate of authority involved.
So, we have that framework to build upon. I think we have practices and use cases that we can build upon and implement through interoperability pilots. I don't think we should theorize on these things in ivory towers and write about them and try to think through them. We should actually get vendors involved, health care providers, institutions to actually work through the bugs, mechanics, the issues that come out of it.
As I said in my testimony, the technology does exist. It has been out there. We can pick and choose. EDIINT actually did that. We chose technologies that existed and we have multiple choices to pick and choose from and I think that is the road that we should go down. But, no, I don't want to give any indication that it is a simple thing to do, but I believe we have the smarts to do it and we have people committed to doing it.
I agree with Glen, that given my experience in healthcare information technology over the years, I mean, and I worked for a National Data Corporation and it took how long for NCPDP to get the next version of their claim transaction out and it was only because of that that the industry shifted and was able to support some of the new -- so, those standards have to be there in order for the industry to move to. Otherwise, there is no impetus for them to do it. In fact, there is push back to do it.
DR. ZUBELDIA: So, if I hear it correctly, either it is advocating an environment where we have a full international PKI and digital signatures in health care, but what Jan and Glen are saying is that they want more something now, today, that even if it doesn't have full PKI behind it, that can be used today, say development product, but can be used to improve upon while the full blast PKI is deployed and that may be something we have to change as we learn from it, which is feasible under HIPAA. It can be changed every year as we learn from it.
Is that what you are driving to?
MR. MARSHALL: Yes. From my perspective, PKI and digital signatures are not a chicken or egg or a sequential process. They should be happening at the same time because they are two fundamentally different issues. PKI is about a structure in which trust can be established and exchanged. It becomes a formal structure for that. I does not really require a specific digital signature technology or standard to -- for the, if you will, administrative protocols and what have you to be set up. Obviously, there is an automated implementation of PKI and X509, for example, goes after some of that, but, you know, frankly, I think the word for PKI is at this point independent from digital signature.
Within a trial or small scale implementation, you can establish the trust by some form of bilateral agreement or something that is perhaps less formal than a full scale PKI, but you can still achieve an interoperability test at a sufficient scale to prove the work of the idea.
MR. WAEGEMANN: I would say, Kepa, you are right, the two have to be done parallel. What we have to realize when we talk about PKI is it is a very complex issue because now we are talking about registrational -- it is really credentialing organizations, if you like, but at a much deeper level than when we can do right now. We need to know for signatures not only is this is an M.D. versus maybe a nurse or a technician, but we need to know that this is a pediatric psychiatrist and has fees credential and specific privileges for accessing information and for signing. So, there is a very different infrastructure needed.
The second point I want to make is that for PKI or for the idea of digital signature within a PKI environment, there is a need for many specific standards. We can't just start right now with how to reidentify a physician. In Europe, they have standards. It is a smart card. It may be biometric identification device. It could be in terms of approach of shared secret. It could be a software approach. There are four or five where maybe standards are needed. What is acceptable and what is not acceptable.
Then we go into the question of our group. Then we go into the whole question of certificate authority standards. Then we get into the whole question of registry authority standards and so on. It is a whole framework of many detailed standards, which are needed long term.
So, as we just have been saying, we work on some kind of coordination on a short term one and, again, I am saying something, which may haunt me. It will not be perfect, for sure. It will not be perfect. Because we cannot create short term something perfect period.
DR. COHN: I don't think you have to worry about that one haunting you.
DR. ZUBELDIA: So, if I hear it correctly, the three SDOs in the room -- and I haven't heard much from Dan, but I know it will be enough -- the three SDOs in the room have agreed to work together to put together a short term solution for signatures, under the coordination of HISB and then Peter has agreed to coordinate that effort, including X12 and potentially a few more than you are discovering through HISB and maybe with the assistance of NIST and whomever else, you agreed to do that --
MR. WAEGEMANN: FDA.
DR. ZUBELDIA: Okay. FDA, DEA. Okay. Perfect.
And then you will lead a long term effort later to do -- in parallel. Everybody has agreed to do that.
DR. COHN: Has X12 agreed to do that?
DR. ZUBELDIA: X12? I don't know.
Let's try to get an MOU tonight.
MS. WEIKER: This is Margaret Weiker with EDS and DSMO chair.
In regard to X12, as Kepa said, they were not at the multiple joint meeting that we had in Orlando and they are not here today. So, I don't think anybody in this room can say whether X12 has agreed or not to participate.
DR. ZUBELDIA: Could I ask, Peter --
MS. LOVORN: But the pressure will be applied.
DR. ZUBELDIA: Could I ask Peter to try to get that sort of consensus reflected in the letter to the committee?
MR. WAEGEMANN: Accepted.
DR. ZUBELDIA: In a letter to us saying this is the agreement of the SDOs. It doesn't have to be a full-blown memorandum of understanding. It is just reflected in a more formal way because they are not here today.
MR. BLAIR: Is there anything that we could do on our committee today that might be a constructive element, encouragement, an endorsement, a statement of some type, to indicate that what we seem to see here is the beginning of convergence among several SDOs with concepts for short term and long term planning, with agreement on coordination.
We have the beginning of it here and if our Subcommittee on Standards and Security in some way endorses or encourages that, maybe that could help encourage the participation of X12 to join that. Is that something that could be constructive? Can we do that in some way?
I guess I am really asking, you know, Simon and Kepa, if they had a statement -- you know, we haven't done those types of things in the past. So, I am just trying to think of something that is constructive within the context of our normal operations.
DR. COHN: Well, I think, normally the process would be is that we would draft a letter both supporting the effort and thanking the standards development organizations for collaborating on this very important HIPAA initiative. That would be something that we would draft and I think that was agreed to at the full NCVHS meeting, which luckily is only -- is it two and a half weeks away. I guess the question is I think between now and then it would be useful to know if, indeed, all of the SDOs are participating in this or not.
DR. ZUBELDIA: There is a SDO meeting next week in Seattle and I intend to bring this up in the management meeting and get their reaction.
MR. BLAIR: Maybe you could have our verbal support.
DR. ZUBELDIA: -- disappointment for not being here and encourage them to participate -- fully participate in the effort.
MR. STANIEC: This is Dan Staniec, NCPDP.
How would you and the rest of the committee like to be updated on how we are doing on our process? Do you want us to come back again or reports or --
DR. COHN: Well, actually, I have a thought. I mean, we actually have a hearing which is primarily on PMRI issues --
MR. STANIEC: Because I think we are talking March 7th as our next meeting. We are going to have some conference calls. May 12th will be one we are going to have in Boston, rather after TEPER(?). I am just -- what are your expectations of time frames.
DR. COHN: In dealing with these things, I put on my project manager hat. I am a physician, but, you know, physicians do everything in this society as you know and I generally sort of say, gee, when is the project plan going to be done and agreed to and I think you indicated towards the end of March.
MR. MARSHALL: That is the intent, yes.
DR. COHN: That is the intent and I guess the question I would ask is in terms of making sure that things are going okay. Usually once a project plan has been ironed out, that is the time to look at it and congratulate everybody on moving forward.
Do you think it would be done by the 19th or 20th of March?
MR. MARSHALL: I can't say that because part of the existence of such a plan requires a framework, if you will, and I would not want to commit to a final date until the March 7th HISB meeting.
However, I would also point one other precipitating event that will be extremely helpful, but I believe that this committee can help with. Certain of the use cases that would be involved in this require the policies be known. Currently, there is not a final security regulation.
Anything you can do to hasten that getting published will help this project immensely.
DR. COHN: Thank you. We are actually considering our annual report to Congress tomorrow and that may be reflected in that. It is hard to know. But there may be some --
MS. LOVORN: We are sorry. We had to get that in there.
DR. COHN: That is fine. I guess what it is -- Kepa, you may have other thoughts on this one, though. You know, you have our support on --
MS. LOVORN: Also, in jest, you can fund the bar beer at the March 6th and 7th meeting so that we can get along.
MS. FYFFE: To clarify, you are talking about the security final rule, not the signature that is going to come from commerce. Right?
DR. COHN: Right. It is being held up and that is what we are trying to get going again.
MS. FYFFE: Okay.
DR. COHN: I think she is specifically talking about the security final rule.
MS. LOVORN: We understand that. It is just that, you know, you can't have privacy without some underlying security and you can't have digital signatures unless there is a requirement for -- I mean, you know, it is all interwoven and it is hard to take it as a separate part and not do one without some hope of the others happening.
MR. WAEGEMANN: Forgive me for coming back to one of the issues I started out with. As I said, we really have two short term projects in front of us. One we talked about, it is the SDO coordination project. The second project is more a political question.
Should or should not signatures be included in HIPAA and my question -- and maybe I don't know if the panel person even is allowed to ask the members for questions -- is do you think that there are ways of furthering that question? Is it possible to create -- I called -- at some point I called Kepa about creating a white paper or what can be done to bring this issue further or is this something where we are quite happy to keep it like a snowball, just pushing it in front of us and it gets bigger and bigger and bigger and at some point something will happen or can I ask what --
DR. COHN: Let me comment. I guess from my view and I will ask others for their opinion, but, you know, when things were stalled for digital signature, we, obviously, held a hearing to see if there was industry agreement that this was even important.
Certainly, I think, we all heard that this was an important industry issue. Now what we also heard is that there was not industry agreement and certainly not SDO consensus around any sort of approach or solution. So, I think our view was that the way we moved this forward is among the things to develop both industry and SDO consensus on.
Certainly, it is nice to talk about digital signature until you have something that you can demonstrate that actually is working, can work and is implementable. It becomes an interesting conversation but not much more than that. That is my own personal view.
Kepa, do you want to comment? Karen and Maria.
DR. ZUBELDIA: I think that the answer to Peter's question is we don't have a choice. The HIPAA law says that we shall adopt the standard for signatures.
DR. COHN: Karen.
MS. TRUDEL: I think I have a different point of view and I hope what Peter is talking about is the fact that everyone has agreed that in theory --
MR. BLAIR: I assume it is Karen Trudel.
MS. TRUDEL: Sorry. It is Karen.
That electronic signatures is important in theory but that none of the HIPAA standards that we have adopted so far have a requirement for an electronic signature of any kind. That is really a very big disconnect. It seems to me that we can develop standards for electronic signature until the cows come home, but until there is a business case, transaction by transaction, I am not sure how practical the approach is. I think that the standards maintenance process, the DSMO process, is the place where people need to say now is the time to say that the claim needs an electronic signature.
MR. BLAIR: Karen, can I react to what you just said? Could I paraphrase it a little bit to make sure that I am in sync with it? All right?
I think what you just told us is that there is a legal technicality of a disconnect in the sense that HIPAA said that there should be an electronic signature, but there wasn't a corresponding statement within the financial and administrative transactions requiring an electronic signature. That is the only thing that has been enacted into regulations at this time.
So, what you are saying is that without some type of SDO or industry momentum moving forward saying that, look, we are arriving at consensus. We feel it is needed, that until that happens HHS was not going to take the initiative to go forward without that happening.
Is that -- did I make a correct paraphrase of your position?
MS. TRUDEL: No, Jeff. To an extent, yes. I think the two things have to come together. There has to be a workable standard and there has to be a business framework for that standard to exist in. I think we need to address both of those things and I guess my additional question is in the absence of a particular articulated business case, like I need an electronic signature on the health care claim, institutional and professional, is there a broad overarching policy statement that can be made about electronic signature that is still worthwhile going forward with? That is what we --
MR. BLAIR: So, in other words --
MS. TRUDEL: I am sorry. That is what we had intended to do when we first put out the security notice of proposed rulemaking.
MR. BLAIR: So, you are saying that in addition -- let's say that this group begins to make progress and they begin to converge and come to a consensus on one or more electronic signatures or with a different variation of use cases with implementation guides, the way they are sort of discussing the direction as, you are saying that in addition to that before that could become a HIPAA standard, there would also need to be created a business case.
Is that correct?
MS. TRUDEL: No. I think you ultimately need both of those, but what we had anticipated doing initially was to say in general an electronic signature standard should meet these very high level criteria. We then went on to say at this point in time there is no business requirement in any of the HIPAA standards, the transactions, for an electronic signature, but as that business case is advanced the specific solution would have to meet these high level criteria.
DR. ZUBELDIA: And the only business case we have heard today could be for the prescriptions and even that is doubtful.
MR. STANIEC: A legitimate business need, the volume is very low, but certainly of great interest to us.
DR. ZUBELDIA: But it will be variable state by state.
MR. STANIEC: Right. The state boards of pharmacy dictate the rules and regulations, yes.
DR. COHN: Maria.
MS. WARD: Maria Ward, speaking now has the role in the attachment special interest group, co-chair in HL7. We have a business case, guys. The current six attachments that are likely to be proposed,while we evaluated those and we did conclude that we don't have a need for electronic signatures.
The state Medicaids actually came to our HL7 meeting about three weeks ago and requested three attachment types to be developed, all of which require signatures. So, we have a very real business case now and we are going to be working very closely with Glen to be able to apply whatever it is we need to apply in a standard fashion to create a standard attachment for them.
So, we have something that we can apply this to now from the Medicaids.
MS. TRUDEL: This is Karen Trudel. I want to follow up on that.
So, those particular business needs would be among the first use cases that you would address?
MS. WARD: Yes. At this point, they requested three attachment types, abortion, sterilization and hysterectomy, all which require signatures. They actually withdrew their request because they hadn't done quite enough homework yet to really be able to come and enter that into the DSMO process. Essentially, that was on the recommendation of the CIG, the attachment CIG, but they are going back and gathering the facts and coming back to us in May.
So, I think we are going to have something very real to apply this to in a real short time.
MS. TRUDEL: I think that is a good way to mesh the processes together.
MS. WARD: Yes, I do, too.
DR. ZUBELDIA: And I don't want to say this but I think I have to, Maria. When you put together those business cases, I think it would be very helpful to put together a business case on how a Medicaid beneficiary is going to get a digital certificate to sign with a digital signature.
MS. WARD: Right. That was already part of our discussions with them, yes. We understand there are a lot of interesting things to address with this.
MR. MOERTEL: Karen, your comment brought -- I am sorry. Dave Moertel from the Mayo Foundation -- your comment about having a business case and having a digital signature for each one of the transactions, I guess I have a differing view as to how that is handled and the use for the public/private key encryption. I am not talking about PKI because I realize bringing in the certificate authority in that process brings a whole other element into this. That is much more difficult.
But as far as the public/private key encryption, we are doing that currently today with the claims transaction. We are doing that currently today with the claims transaction. We are doing it with a number of payers. So, when you are setting a business case for the claims transaction, typically with the paper claim, with the electronic claim, we have signature on file. We are not planning or it wasn't our intent to have a digital signature on that claim.
Is that what you are recommending or are you talking about securing the transactions in a bundle so we can pass those? We already have an X12 transaction that provides an envelope for any one of our transactions that we can secure with the transaction and the envelope, send it. They decrypt it, open up the package and away we go. That is already in process and being utilized today.
So, I need clarification on your comment because it kind of --
MS. TRUDEL: I am not talking about encryption. I am talking about a need for an electronic signature.
MR. MOERTEL: But is it your expectation that we have within the claims transaction an electronic signature or continue to use the process that we have today, basically signature on file within the transaction, and not have --
MS. TRUDEL: That is my point. That is the business decision that people need to think about and bring forward. It was something that I think Peter mentioned at the very beginning. We have this incredible variation between not having any electronic signature or any signature at all. It is just on file somewhere and we are passing hundreds of thousands of transactions worth billions of dollars and that appears to be working okay.
Or is there a need for people to reassess that and say just because we have always done that, is it necessarily the way we want to continue to do that? I am not advocating one way or another. I am just saying that there needs to be a business need established or not as the case may be.
MR. MOERTEL: So, I am seeing two situations here. We have one where we have a signature that provides the encryption for a data file and packages a batch of claims. I have another one where each individual claim has an electronic signature associated with it. Two very different situations.
Am I reading this incorrectly?
DR. COHN: I think we are discussing this right now and I think it is an industry decision, but I think what Karen is commenting on, there needs to be a reason to have a digital signature. It may not be the claims is the reason. It may be something else. She is just positing that there needs to be an industry need.
MS. FYFFE: Dave, in a former life, I feel your panic. We are not -- I don't think Karen is suggesting that it would be a requirement to have a signature on a claim. Okay? That is not what we are talking about here. We are talking about in theory what is the incentive to move the industry toward electronic signature.
MR. MOERTEL: Got it. Okay. With that in mind, let me pose the business case.
We are trying to pass electronically over the Internet claim files with government organizations. We can't do that because this legislation hasn't been finalized. Recommendations for how to secure transactions haven't been finalized. Therefore, we are not authorized to use the Internet, even though we have it encrypted on everything just fine.
So, my business case is I have a need to get away from async(?) communication, which is fraught with problems and drop lines and all that kind of stuff. I want to use the Internet. I want to use it very effectively. I can't do it without this process. There is my business case for the claims transaction, not digitally signing each claim, but signing the package, but yet having it in an environment that is acceptable by HCFA, by the Department of Health and Human Services and by the healthcare industry.
So, even with a claims transaction, I would be very willing to participate. I am doing it today with some organizations, but over our wide area network in Minnesota.
Thank you.
DR. COHN: I think we need to begin to wind this conversation down. Do you have a comment?
What I would like to do is wind this one down and then talk about next steps.
MR. ZUCKERMAN: I am Alan Zuckerman from Georgetown University Medical Center in Georgetown.
The HIPAA NPRM and the ASTM standard mention continuity of signatures, but I haven't heard anything from the SDOs today about what this problem really involves and I see it as a major issue for the NCVHS to take on. Essentially, continuity is extending the interoperability problem over time, beyond bankruptcy, beyond technology change, beyond ownership of intellectual property.
I feel that there may be a need for the government to develop repositories of cryptographic algorithms, of certificate reauthentication and revocation lists that would survive beyond the life cycle of the organizations involved.
I would hope that this issue arises again because I think it is sort of a long, long term issue, but one which is essential to progress.
MS. LOVORN: The short, quick answer is that ASTM has recognized that and we have a subcommittee in process right now looking at those issues to come up with a draft standard in the next six months or so because that is an issue of great -- particularly with the requirements of keeping medical records like in Minnesota of 70 years.
DR. COHN: Now, let's figure out next steps. We seem to have gotten not off track, but we have had some interesting discussions. But we are beginning to sort of comment -- Jeff had sort of said, gee, a letter to the SDOs expressing appreciation for their involvement would be very useful. We are also well aware that there needs to be -- and I think Kepa has raised his hand to have a discussion with X12 so that we can make sure that we are properly writing this letter right and sending it to the right people.
MR. STANIEC: This is not an MOU. This is a --
DR. COHN: No, no. This is --
MR. STANIEC: -- understanding, action item.
DR. COHN: Supporting and appreciating the fact that you are working together, but recognizing that there be a different letter if X12 for some reason is not actively involved. I think Kepa will go to the X12 meeting and discover if, indeed, X12, which we are hoping -- we hope they are involved.
Now, I guess if there is an issue, I guess we would need to consider whether we invite a representative from X12, discuss it with the subcommittee at the full NCVHS meeting during a breakout, to explain why they aren't fully involved if we understand there are reasons and we can seek to mitigate barriers to implementation and progress on this.
Otherwise, we will probably draft a letter of appreciation to the SDOs on this. Now, what we would also like to see is when the project plan is completed, we would like to see the project plan and, hopefully, we can also arrange a presentation at such time as it is completed because I am not hearing that there is a certainty about March. It may be the meeting after that, but we would certainly like --
MR. LUNDIE: We have to transform my personal intent into one that HISB supports.
DR. COHN: We are absolutely supportive of your personal intent. We are helping you along with that.
Is there anything else that we need to do?
MR. SCANLON: Another vehicle to sort of raise some of these issues is the annual report to Congress on administrative simplification of health care. This has been at least -- this is an issue, I think, the committee may want to say a little bit more about.
DR. COHN: Anything else on digital signature for the moment before we now reflect on other things we need to do from the earlier discussions?
Peter.
MR. WAEGEMANN: It is somewhat petty but probably should come from the coordinating organization rather than from HL7. I think it is really a time that has been taken out of one SDO into a neutral ground, which may make it easier for everyone to come to the table. So, I would volunteer when the time comes to work with Glen on that and present on that.
Final comment, anyone who knows about the benefits of signatures or is working on that, please contact me. I am currently trying to work with a coalition of at least two of the big consulting organizations who are trying to come up with some white paper and, hopefully, it is as neutral and as basic at some point to present a business case for signatures.
DR. COHN: Great.
MR. WAEGEMANN: It is just something which is going on. Anyone who has information, please let me know.
DR. ZUBELDIA: Probably the letters from the SDO should be addressed to Peter and then Peter can submit them to us, the letters of saying we are voluntarily participating in this and we are going to be good, addressed to Peter and then Peter communicate with us.
DR. COHN: Okay. So, do we hold off until we receive notice from Peter that other SDOs are not --
DR. ZUBELDIA: We don't have to.
DR. COHN: Still go forward with March then. Okay.
Now, let's talk about the morning activities and all of the data issues and the next steps. Now, what we are hearing -- Margaret and Maria, are you there?
MS. WEIKER: We are still here.
DR. COHN: Why don't you come to the table, if you would.
Obviously, what you have heard is, I think, one of the issues that you had on your docket. We are hoping to sort of move forward on a fast track to HHS in terms of the NDC codes, in terms of a letter to HHS, but there is also --I think we are now aware that you are likely -- probably in your mailbox, the DSMO, are a whole bunch of issues and likely to be more that are sort of a combination of business issues, as well as maintenance issues.
I think that there are probably some other similar data items that I know that HHS has received, but I don't know is at liberty to forward them to the DSMOs. But I think the question gets to be is how most efficiently to make sure that these issues get to the attention of the right people and the right group so that investigation can occur and some sort of a response be brought back to the NCVHS.
Obviously, part of the question gets to be is, gee, are you all willing facilitate that process or should some of this stuff just be sent directly to X12, since many of them are dealing with X12? What is your view on this?
MS. WEIKER: Okay. We have a plan.
DR. COHN: Good. Let's hear the plan.
MS. WEIKER: The time frame for the February batch, which I have no idea how many are in there, Dave, expired last night at midnight.
MR. BLAIR: The time frame for what?
MS. WEIKER: The time frame for entering for the February batch because there are cutoff dates to meet each month's batch cycle. That was last night at midnight, Eastern time.
MR. BLAIR: I am sorry. I am missing something. Batch cycle for what?
MS. WEIKER: The change requests for the DSMOs.
MR. BLAIR: Oh, okay. Thank you.
MS. WEIKER: -- to see if they want to participate. I am going to request from Steve Bass tomorrow that that be sent out no later than Monday. So, all of those change requests that are sitting there now can get to the six organizations so they can decide if they want to collaborate or not. This gives the opportunity, since X12 is meeting next week, to review all of these change requests that have come in.
So, that is the first step. The second step is a definition of what is maintenance and what is modification, definitely needs to be determined and communicated to X12, NCPDP, as well as HL7, though HL7 doesn't have any standard at this point that has been finalized.
But that needs to be established and communicated. So, the work groups in X12 that are actually looking at these requests, whether it came in through the errata process or the DSMO process, know how to categorize these and then they know what paths they may follow. Do they follow I just update the guide with an addendum that just goes through the SDO process or does this go back through the DSMO process?
So, it goes back to the chart that Mary kind of presented with these, modification and what is the path. X12 will -- and I say this as I will take a big stick -- will look at all the errata and determine maintenance, modification, all of the change requests that have been done at that time that they meet will get addressed. They may not have the technical solution but they need to have their business issues or business analysis done and completed and posted to the web site.
Now, the NUBC and the NUCC have also expressed interest on several of the requests in the first batch, as well as the request in the second batch. I will be talking to them and the fact that they need to get their analysis moving. What I am going to try to do is shorten that 90 day time frame and see if it is not doable in 30 to 45 days.
So, I understand the urgency. Maria understands the urgency. I know Karen understands the urgency and I assume, Karen, you will be at X12 next week? No? Okay.
Kepa --
DR. ZUBELDIA: Yes.
MS. WEIKER: We understand the urgency and this will be communicated to the leadership of X12, as well as to those co-chairs so they can move this along because of the short time frame.
DR. COHN: I want to add just one or two little pieces. I have to look at Kepa and others to make sure that we are sort of doing things appropriately. But there are a lot of what you describe as errata and minor maintenance issues that I doubt will take a lot of X12 time. But there are some -- also mixed in here some very significant business issues. Part of my view, the business analysis needs to go back and identify -- go back and sort of refresh ourselves and have them refresh themselves with what is the business need for some of these things.
I would welcome guidance from X12 and the DSMOs coming back with recommendations on what ought to be happening with some of these things because it may be that there are requirements where there are other ways to handle that business need, but then there also may be issues where there used to be a business need a couple of years ago and there isn't anymore.
Obviously, that sort of guidance for the full committee would be -- and for the subcommittee would be very useful. Now, are there other things that we need? I am looking at others at the table here to see if they are -- I mean, that would be the sort of information that would be invaluable to sort of figure out how to deal with some of the business issues.
Kepa, do you have a thought on that one?
DR. ZUBELDIA: I think that what is clear is that the business issues are all going to be modifications. So, if there are any business issues in the errata list itself, they need to be sent through a DSMO process because they are going to be modifications. I think that is one thing that X12 needs to go through the errata list and instead of looking at what is a showstopper, what is a no showstopper, look at is this a business issue. If it is a business issue, take it through a DSMO process.
If it is not, well, it is a maintenance issue, let's get it fixed. I think that has to be the process.
MS. WARD: An extension of that is something Margaret mentioned this morning and that is at a certain point in time we have to say -- we can't just keep fast tracking everything for the next five years. So, at a certain point in time, we have to say that these are the things -- I mean, this batch cycle, you know, rears its ugly head every month. So, this just keeps happening every month.
So, if we say 45 days, is that 45 days from the December batch or the January batch or the February batch or the March batch? I mean, we have to talk about a point in time where we are comfortable in saying this is it. This is what is in the key. These include the errata, I am sure, because that was a very focused, special effort to try and call out issues with the implementation guides and include the things that we have in front of us now, but at a certain point, we have to say there is a process that is going to be followed and everything that proceeding date certain, whatever that is, is going to go down a different path. It is a fast track path that we probably have some control over pushing the dates on, but I don't think we can do that forever.
DR. ZUBELDIA: The concern is that this is a fundamental change of a process that has been followed so far. The errata list was sent through the Washington Publishing web site with the intent to identify what are the showstoppers and what are not the showstoppers.
For instance, an example in the implementation guide that is incorrect or syntactically incorrect was not considered a showstopper because you could work around the example and not use the example.
So, the intention was to not correct any of those little things and only correct the big things. I think now we are completely shifting gears and saying, no, that is not the intention. The intention is to correct everything that is just purely maintenance, just get it fixed, and everything that is a change, send it to a DSMO process for consideration.
I think it is a fundamental change over what has been done in the past.
MS. WARD: Kepa, Margaret and I also all wear X12 hats. I mean, I co-chair a work group in X12, just like I do in HL7. So does Margaret. So, we are all, I think, treading very lightly in actually committing X12 to anything because it is really not our job to do that, but trying to push it to say we are doing everything in our power to make sure that the X12 management team is in line with what they need to be in line with, to get the results that we need. Today, I think that is all we can do and we will all be at the management meeting of X12 next week and, you know, represent the opinions of this group and our recommendations to them and just hope that we can get that group to pull together and do what they need to do because most of this does fall in X12's lap.
DR. COHN: Mary, do you have a comment?
MS. EMERSON: Yes. I just wanted to make one comment and that is that the -- you know, it came out in this morning's session -- the emphasis on the showstoppers was to try to make this deadline of within the first year. That may have been sort of really an artificial deadline to try to meet anyway.
Were the work groups not trying to meet the deadline of changes within the first year, they may not have concentrated just on the showstoppers. Maybe there is not really a need to do that.
DR. COHN: Well, actually, I think I would disagree. What I think we are all hearing is is that -- I think my comment to you about your time line was that, indeed, this stuff needs to be cleaned as much as possible so that people can develop software to implement. That almost redoubles the issue as opposed to delays it. I mean, there is nothing --
MS. WEIKER: But if the list were ready slightly after the first year, then there would be more flexibility in what could be included in it and it would not have to be limited just to showstoppers. So, that is the point I am trying to get across.
DR. COHN: I see.
MS. WARD: And part of that, the distinction between -- in some cases, I think that is fine. In cases like is it NDC or HCPC, I don't think that is fine because those are substantive issues. If it is a question of adding a data element or changing syntax, no -- or something like that, that can wait.
So, the showstopper designation that we gave it in X12, that was sort of a value in trying to call those out. Call modifications now -- I mean, we are talking about the same thing. We are changing the terminology. We are calling them modifications. We are going to put them into the DSMO and we are going to fast track that somehow and then, I think, that is what we need to do.
DR. ZUBELDIA: Yes, but the errata work group was working under the concept that the showstoppers did not have to go through a DSMO process. They were going to be addressed from within X12 only and that the non-showstoppers were going to be ignored. So, now, instead of addressing within X12, even though it is a showstopper, it has to go to DSMO. I think that is --
MS. WARD: I am not sure that the errata work group was working under that premise. I was part of that, not fully committed to it, but did as much as I could with it and the one conference call that I did attend -- I mean, part of the real problem was there was a disconnect there and there was this effort going on and people were focused and going full speed ahead in errata doing what they thought they needed to do and we weren't having that conversation in the DSMO Steering Committee at the same time.
They were doing what they were doing and we were out here doing what we were doing and now we see that there is a very real overlap between the work that is being done.
MR. BLAIR: That perception wasn't errata then, huh?
DR. ZUBELDIA: Needs to be modified.
MS. WARD: So, again, I think this is an -- what is X12 going to do with this and about this and how are we going to handle this in X12?
MS. EMERSON: The errata group, which I did participate in their calls and even sought some advice from our general counsel on how some of the questions could be answered. They were under the impression that the errata -- fixing those errata would go through the DSMO process.
I agree with you that there was a disconnect.
MS. WARD: I was never under that impression from the errata, but then I was from reading e-mails, but not from the calls that I was on. So, I think there might have just been confusion about that.
MS. WEIKER: I think there was confusion that I think we have cleared or we will clear this up with its maintenance or its modification and come up with clear definitions and this showstopper, no-showstopper and all of these different technologies have got to stop. We have to come to an agreement and we have to move forward and move forward quickly.
DR. COHN: Actually, when I am thinking on the basis of this conversation, we haven't talked about the agenda for our breakout meeting later on November -- February. It is February right now, not November. The last meeting was November. But really it would make sense to devote some time to meet one or both of you, also having somebody from X12, who was in a position in high level authority that they can speak for the organization and make sure that we have gotten all of this straightened around and that the process is going to work optimally to figure out where the process is after that week long X12 meeting, which is happening next week.
I think we are all -- there are a lot of items for this subcommittee. We have got a long list of activities and issues. Issue No. 1 is making sure this implementation proceeds well because without it there isn't much else to HIPAA. So, I think right now we are sort of at the rubber meets the road sort of stage of activities.
You have people talking about this at a high level. Now people are doing serious analysis and luckily we are not coming up with hundreds of pages of issues, but we are coming up with many pages of issues and we need to make sure that they are handled in a reasonable fashion, relatively quickly so the industry implementation can continue.
So, I think -- Kepa, do you have a thought on that one? Am I -- I mean, I think we just need to keep real close to this for awhile because we really are -- it is really a critical juncture there. I mean, industry needs to be assured that the issues are being dealt with quickly, thoroughly. Things are being streamlined to make implementation as easy as possible for them.
Certainly nobody wants to start going out and doing the implementation or opening up your software to make major changes, to then discover three weeks later, oh, no, we thought it was going to be this way instead.
I think everybody is beginning to do that right now. They are not getting nervous but they are just beginning to start opening things up. The analysis is just being completed in multiple different environments. So, let's take advantage of that opportunity.
Karen, do you have a comment?
MS. TRUDEL: I do. It seems at the very crux of this is the guidance on the difference between maintenance and modification and I know -- I have some thoughts about it and I guess I am asking how we can -- who needs to participate and how the process would go to develop that definition because it is just central to all the next steps.
MS. WARD: I think we need to do that before the X12 meeting, which is Sunday. So, I mean, because this is where it is going to be starting. You know, this is where we are going to address it and, you are right, we have to be very clear about the direction that we give the work group co-chairs in X12 as they take a laundry list of items and start to evaluate them.
MS. TRUDEL: Would you like some general feedback from us to use as a starting point?
MS. WARD: Yes, absolutely, Karen. Margaret and I can carve out some time prior to the actual meeting to devote to this and work on this when we get to Seattle.
MS. WEIKER: But if you would give us general thoughts, comments, opinions --
MS. WARD: Simon, are you -- what is your request of us? Is it for us to come back and talk to you again or is it for a report or is it just a status?
DR. COHN: I think what I am -- I guess there is a couple of things. I mean, first of all, I think we are looking at March 22nd -- February. Okay -- committee meeting, February 21st. We will have a breakout of the subcommittee in the afternoon. I think we need -- sort of a status check with you and X12 to sort of understand what the process is, how modifications and other things have gotten straightened around, what the time frame is going to be for -- appears to be for resolution and recommendations on these things. So, I guess it is a status report. And it is not the final answer because I don't expect to have the final answer in three weeks, but I think setting the stage for, hopefully, coming up with something in the March to early April time frame to sort of really deal with all of the -- at least as many things as we can come up with at that point.
MS. WARD: Okay. The NUBC and the NUCC also meet the week prior to that and they have opted in on a lot of those. So, perhaps we can try and get some sort of conclusions out of those groups as well prior to coming back.
DR. COHN: Okay. Kepa, do you have a comment on this one? I am trying to put the processes together as well as we can. Obviously, I am a little concerned that there is such a long space between the March and the June -- February and the June NCVHS meeting. But I think we can probably get leave from the committee to begin to process a lot of these issues and probably come up with some interim letters between then and June and begin to give the industry some guidance. We don't have to wait and just hold things up until the June full committee meeting. So, our idea would be is like let's get moving on these things. Let's deal with them and let's get things out to everybody as quickly as possible.
You guys all have houses in Washington, D.C.?
MS. WARD: No. I was bound for Hawaii again that day. I can put that off a day.
DR. COHN: Okay. That is appreciated.
Well, was there anything else? I mean, I am trying to sort of think about -- I mean, we will think a little more tomorrow I am sure and try to firm things up a little bit. As you can tell, I think my concern is is that with processes like this, sometimes it is very useful to take a very close look and make sure that the process is working well.
Do you have a comment? You have been very quiet.
DR. SHORTLIFFE: Yes. This is Ted Shortliffe.
It may seem unusual for me to be this quiet, but I have heard more new acronyms this afternoon than I have in a long time. There is clearly a learning curve in this community. I will be absorbing as much as I can and before finally figuring out just what the DSMO is.
MS. WARD: We don't necessarily like all of the acronyms.
Would you like us also to make a formal request at X12 between the three of us that somebody either from the healthcare group or X12 be here on that day, on February 23rd?
DR. COHN: Yes. If you have any problems, I think we will have HHS work with us to make sure but I think that they know in advance would be very appropriate. It may help them decide who needs to be there.
MS. WARD: Okay.
DR. COHN: Other issues? Is there anything we have forgotten today so far?
Okay. It has been a long meeting and we want to thank everyone for tremendous participation and involvement. Obviously, this is getting to be very interesting at this point. I think it is going to be successful, but we obviously need to move quickly at this point.
Okay. With that, it is 5:25. We are about ten minutes past adjournment, but we are going to adjourn. We will start off at 8:30 tomorrow morning.
[Whereupon, at 5:25 p.m., the meeting was recessed, to reconvene at 8:30 a.m., the following morning, Friday, February 2, 2001.]