[This Transcript is Unedited]
Hubert H. Humphrey Building
Room 705A
200 Independence Avenue, S.W.
Washington, DC 20201
Agenda Item: Call to Order. Welcome and Introductions.
MR. REYNOLDS: Good morning. I want to call this meeting to order. This is a meeting of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics.
The committee, as you know, is a main public advisory committee to the U.S. Department of Health and Human Services on national information policy.
I am Harry Reynolds, co-chairman of the subcommittee, and I work at Blue Cross Blue Shield of North Carolina.
I want to welcome my co-chair, Jeff Blair, fellow subcommittee members, staff and others here in person. I do want to inform everyone that this is a public meeting. We are broadcasting on the internet. So, please speak clearly into the microphone at your place. Also, the meeting is being recorded and transcribed.
With that, let's start with the introductions around the table and then around the room. For those on the subcommittee -- this is in reference only to those on the subcommittee -- if you have any conflicts of interest, please note them as you introduce yourself.
I will start off. Obviously, later on the Blue Cross Blue Shield Association will be testifying, and I am a member of the Blue family. I will note that right up front.
MR. BLAIR: Jeff Blair, vice president, Medical Records Institute, co-chair of the subcommittee, and I am not aware of any conflicts of interest.
DR. STEINDEL: Steve Steindel, Centers for Disease Control and Presentation, staff to the subcommittee and liaison to the full committee.
DR. HUFF: Stan Huff with Intermountain Health Care, University of Utah at Salt Lake City. I am a member of the committee and the subcommittee, and am not aware of any conflicts of interest for issues that are coming before the committee today.
DR. FITZMAURICE: Michael Fitzmaurice, Agency for Health Care Research and Quality, liaison to the full committee, and staff to the subcommittee on standards and security.
DR. ZUBELDIA: Kepa Zubeldia with Claredi Corporation.
MR. BECHTEL: I am Don Bechtel. I am a standards and regulatory management for Siemens Medical Solutions.
MR. HAWKINS: John Hawkins, a product manager with Quadramed.
MS. GREENBERG: Marjorie Greenberg from the National Center for Health Statistics, CDC, and executive secretary to the committee.
DR. WARREN: Judy Warren, University of Kansas School of Nursing, member of the committee and member of the subcommittee, and I am not aware of any conflicts that I have today.
MS. PICKETT: Donna Pickett, National Center for Health Statistics, CDC, and staff to the subcommittee.
MS. SQUIRE: Marietta Squire, CDC, NCHS, and staff to the subcommittee.
MR. NACHENSON: Stanley Nachenson(?) from the Office of E-Health Standards and Services at CMS.
MR. SCHUPING: Jim Schuping with WEDI.
MS. GILBERTSON: Lynne Gilbertson, National Council for Prescription Drug Programs.
MS. WARD: Maria Ward, representing Health Level Seven.
MS. BOYD: Lynn Boyd, College of American Pathologists.
MS. TOPER: Laura Toper, National Council for Prescription Drug Programs.
MR. CHAMBERLAIN: Dale Chamberlain, vice president of strategic standards management for Express Scripts.
MS. WILLIAMSON: Michelle Williamson, National Center for Health Statistics, CDC.
MR. REYNOLDS: Okay, looking at our agenda today, we have a lot to do in a short period of time. I will ask each of the presenters to remain crisp in your delivery, and help us get through this, because we are real excited to hear from everyone.
I would also mention to the committee that Michael did what I would consider an outstanding job of putting our draft letter together last night. You should each have a copy of that letter at your place.
The plan today is to have everyone to have read it by the end of break this morning. We want to spend a few minutes on it.
As you know, this is a fast track effort, faster than we have maybe ever dealt with. There were hearings yesterday, a letter today, and hopefully to the Secretary next week.
I would also like to request that those of you that were on panels yesterday related to this item, please take a look at it.
So, as we take a look at this just for a few minutes after break to make sure we have substance, that there is no glaring mistake in there as far as what we have actually said, I want to give you that opportunity.
So, if you would see me at break, if you have any changes, I would appreciate it, because we are not going to have everybody standing up going through the letter. That is not going to work out.
So, we are going through a fast track procedure on this particular one, but I do want to give you the opportunity to read it, review it, and make your comments.
So, moving forward, I would like to welcome our first panel, Kepa Zubeldia from Claredi, a long-time member of the industry, Don Bechtel from Siemens, and John Hawkins from AFECHT. So, Kepa, let's start with you, please.
Agenda Item: Updating HIPAA standards: The Vendor Perspective.
DR. ZUBELDIA: Thank you, Mr. Chairman, and thanks to the committee for the opportunity to testify today on the topic of updating the HIPAA transaction standards.
I am going to center my remarks on the X12 transaction standards, although some of the recommendations at the end would also apply to the NCVHS standards.
The definition of EDI that I found in Wikipedia, it is a very generic definition. It reads: Electronic interchange, the computer to computer exchange of structured information by agreed message standards from one computer application to another by electronic means, and with a minimum of human intervention.
I think it is a very realistic definition because it says minimum of human intervention. In the past, I have seen a lot of definitions that would say without human intervention.
The Wikipedia also discusses a little bit about the problems of interpreting the data. It uses an example of packaging, which is not an perfect example, but it is a very relevant example.
It goes like this: If a sender is going to send, in this case let's imagine it is chewing gum, packed six sticks to a package, and the receiver expects 12 sticks to a package, how do they communicate this, how do they agree on what a package means.
The solution, from the EDI perspective, is to agree on a common definition in the middle, that doesn't satisfy the sender or the receiver, but they both agree to convert their measurements, and to convert the data and the content and the definitions to this common definition in the middle.
I have a picture here that shows the sender sending the chewing gum in six sticks to a pack. The EDI definition counts stick of chewing gum instead of packages, and the receiver is re-packaging it as 12 sticks to a package.
EDI, in that sense, is both a connector and an isolator. EDI connects both trading partners, but isolates the trading partners from their differences, isolates them from each other.
EDI provides a common format definition, the common data content definition, but presumes that the trading partners have different business processes.
The trading partners don't need to know each other's business process. In fact, they are better off if they don't know each other's business processes.
The opposite would be when the receiver says, you need to send me the information the way I want it, which is 12 sticks of gum per package, and then another receiver says, no, I want six sticks per package when you send the information -- not the chewing gum, when you send the information.
At the end, the sender of the information has to accommodate each one of the receivers independently. So, by going to a common format, understood with business rules, understood by both ends, even though the business rules may not match either end, they can agree on understanding the data content.
Now, this affects interoperability. The fundamental -- there are two fundamental concepts in EDI that I want to talk about. There are other concepts. These two are important.
One is if the sender sends the data after converting from its internal representation into the EDI representation, and the receiver converts the data from the EDI representation to its internal format.
So, the sender may have an internal representation that is in grams, and in the example you have on the screen it shows a fixed record length format that says 0001500 grams.
The EDI representation may be 1.5 kilograms, and the receiver's internal representation may be three pounds, five ounces, because it was supposed to be three pounds 4.9 ounces, but they round up.
So, that is something that the receiver can do, and everybody can understand the data, even though the units of measure are different, the representation is different. As long as there is a common EDI representation that everybody converts to, then both ends can interoperate.
Now, there is another fundamental concept in EDI, that the sender has to send the data as per the agreed implementation standard.
For instance, all the required data elements have to be sent. Any situational data elements that are appropriate to that situation must be sent, and there may be additional option data that is sent.
Now, the receiver -- this is a very key element for interoperability of EDI -- the receiver uses the data as needed by its business process.
You ignore any data element that you receive and you don't need. You just ignore it, and you reject EDI messages only if you cannot process it because it lacks the data that you need.
You never reject anything because it has something that you don't care about. That is unheard of in EDI, except under HIPAA.
So, the HIPAA standards support this common administrative process, such as claim eligibility, claim status, referrals, and the message standards define the data exchange in support of specific processes.
Now, the assumption here is that the process model is known and common to both parties. It is generally well understood.
So, when the sender sends the information for a claim, the assumption is that everybody knows what a claim is.
Therefore, the standard in the middle, that A37 that we so much know and love, is a representation of a well known and well established business process called a health care claim.
Now, that is not really the case, but that was the assumption when the standards were written. So, through the HIPAA process, companion guides surfaced that outlined the differences in the process.
A payer issues a companion guide, not because they need to have different data content or different data format, but essentially to explain, this is the process that we follow, and this is what we understand as a claim.
It is important to realize that the companion guide explains differences in the process. Companion guides are issued by the receiver of the transaction, and define those unique process requirements.
They do so by specifying some data elements that are required. For instance, I need a medicaid provider ID, or I need a UPN number, because my process requires those. I need a taxonomy code when whatever the requirements are, because that is a process requirement.
Then there are additional specified process requirements in the companion guide, such as certain claims need prior authorization. The PPO claims have to be sent to a third party re-pricer, and so on.
The companion guides require the sender to make changes for each training partner. The problem here is that this concept that I was talking about two minutes ago, that the process in the middle is independent of the process of the sender and the process of the receiver, is totally being violated under HIPAA.
The process of the receiver is being pushed to the sender, where the sender has to understand the process of the receiver in order to send the transactions correctly. That is a fundamental problem.
Let me take a side track for a minute to talk about interoperability. What is interoperability? I will first start with a definition of inoperability.
When two systems, products or components cannot be made to work with each other, they are called to be inoperable.
For instance, unleaded gasoline in a diesel engine, you can't make them to work with each other. An AC motor and a car battery, a floppy disk and a CD drive won't work with each other.
However, the middle example, the AC motor and the car battery, that could be made to work if you put an alternator or an inverter in between.
So, that brings us to the second concept, which is operability. Operability is when two systems, products or components can be made to work with each other through some sort of change, adaptor or custom interface.
For instance, I have on the screen some pictures of transformers. You go to Europe and you probably need a transformer to go from 220 to 110. Sometimes you also need a plug adaptor. This plug adaptor gives you operability with the European outlets.
Under X12, under HIPAA X12, the operability could come in the form of a translator. The practice management system or health information system produces NSF or UB92. That, through a translator, gets converted into an A37, which makes it operable with the trading partners.
I say operable because there is not one A37. There is a rainbow of A37s. Because of these companion documents that I was talking about, there is a multitude of business requirements that are being pushed to the sender, and each one of those is causing a different version or a different flavor of the A37. So, you end up with operability because you have to make changes for each business partner at the other end.
Now, what is interoperability, then? It is when two systems, products or components work with each other without change, adaptor or custom interface.
So, there is a fundamental difference between operability and interoperability. For instance, if you look at the bottom of your lap top power supply, you will see that most of them say AC input from 100 to 240 volts, 60 to 50 hertz.
That is interoperability. You can plug it in anywhere in the world and it will work, as long as you have the right plug or outlet, but it will work.
So, in terms of HIPAA transactions, the desired goal is interoperability, where the practice management system can send a transaction to a payer, and this same transaction can be sent to all payers.
That would really be interoperability. Where we are today is more or less operability, sometimes interoperability.
So, going back to that slide I had a few minutes ago on EDI interoperability, when the sender sends the data per the agreed implementation guide, and the receiver receives the data as needed by their business process.
Now, a fundamental concept here is that the receiver is going to ignore any data element not needed by the receiver, and reject the message only if it cannot be processed because it lacks some essential data. That is a fundamental concept of EDI.
Let me talk about a couple of HIPAA myths. The first myth, if a required data element is not readily available, it is okay to send a filler or a default value.
We see this in HIPAA X12 all the time. If you don't have a social security number, oh, well, send nine nines or nine zeros.
If you don't have a date of birth, send something like July 4, 1776. That looks like a good date of birth. It will pass most of the translator validation, but then the business content is not there, or is it.
The reality is that if the data is needed, only real data should be sent. If the real data is not needed, and there is a need for a filler value, then you have to question whether that requirement is a legitimate requirement in the implementation guide and, if it is not, then it should be removed.
I want to say here that the version 50 guides that are being proposed for X12 for adoption under HIPAA are much improved over version 004010. They are much, much better.
Let me talk a little bit about interoperability and business concepts. Some of the implementation guides under 005010 have different business concepts than the 004010 guides.
For instance, the 004010 guides have a concept of billing provider and pay to provider for the claim, as the entity billing or the entity receiving the payment being different.
Under 005010, that is gone. What that means is that the entire industry is going to have to operate under a slightly different business concept, and has to map their operations to how that business concept works.
There are a few other business concepts that apply to some specialties, like chiropractic, ambulance. Some of the requirements of the old guides and requirements of the new guides are different.
The HIPAA implementation guides reflect both business concepts and format. The business concept in the middle, that everybody has to agree to in order to use the guide is not clearly understood by the industry today. It is slightly different from what the industry uses today, and it is definitely different from what the industry used under 004010.
So, we are talking about interoperability and backwards compatibility. Yes, there is, to a great extent, a lot of backwards compatibility, but there is a gap between 004010 and 005010. They are different. You can't just go and convert from one to the other without filling the gap.
Now, another HIPAA myth, a receiver of a transaction must reject an imperfect transaction, even if it would be otherwise usable.
This is a terrible HIPAA myth. For instance, an invalid taxonomy code should cause the claim to be rejected, even if the user or the receiver does not use taxonomy codes at all, or if a proprietary provider ID is sent and the receiver is using DMPI -- I am talking in the future now, a receiver that is using DMPI and also receives a proprietary ID in the transaction will be required to reject that claim.
That is wrong. The reality is that the fundamental concept of EDI is to ignore the data that is not needed. Don't cause a rejection. Just ignore it. If you don't need it, why reject it.
Now, where does this myth come from? The source of this myth is hard to trace, but I believe it comes from an FAQ that was posted way back when on the ASPI web site with FAQs.
This is very hard to read on the screen, so I have given you the next slide. It goes something like this. It is FAQ number 533.
The question is, if a health care provider electronically conducts a non-compliant transaction -- in parenthesis, transmits an old national standard format or a proprietary format -- directly to a health plan after the transaction regulation compliance date, and the health plan accepts and processes the non-compliant transaction, who is in violation of the regulation? Is it the health care provider or the health plan?
Then part of the question also says, does the acceptance and processing of a non-compliant transaction by a health plan from a health care provider constitute a trading partner agreement between the health plan and the health care provider.
The answer from HHS was -- this is back in 2001 -- if a health care provider electronically conducts an non-standard transaction with a health plan after the transaction regulation compliance date, the health care provider and the health plan are both out of compliance.
Now, the answer keeps on going, but this, in essence, violates that fundamental principle of EDI that, if you don't need the data, you can just ignore it.
This has been interpreted by many lawyers in the industry probably without adequate EDI knowledge as a requirement for the receivers of the data to be -- how can I say it -- overly strict in the receiving of the data.
If something looks like it has data that you don't need, and it may be incorrect, just reject it. That has created a tremendous problem in X12.
So, X12 has tried to make this easier with the new implementation guides. The current implementation guides have three requirements, three definitions, one for required, one for not used, one for situational.
For required it says, it must be used to be compliant. If something is required, you have to use it. For not used, should not be used when complying with the guide. For situational it says, the item should be used whenever the situation defining the note is true. Otherwise, the item should not be used. A note rule appears in the note. The item should be sent if the data is available to the sender.
This seemingly simple definition of what is required, not used, and situational has caused endless grief in the industry, because it is being twisted and interpreted a million different ways.
So, X12 tried to put an end to this by having very well defined requirements that say, required, not used, and there is still the situational requirement where it only says situational.
Now it says, situational, required when whatever the condition is. If not required by this implementation guide, it may be provided at the sender's discretion, but cannot be required by the receiver.
The other situational option is, required when whatever the situation is. If not required by this implementation guide, do not send. That makes it very clear, send or not send.
I think the intent was there in 004010. This 005010 version makes it even more clear what should and should not be sent.
So, along with these four definitions, there is a very detailed table that says, for instance, if the element is required and the item is sent, that complies with the implementation guide.
If the element is required and the item is not sent, it does not comply with the implementation guide. If the element is situational and the situation is false, and the element is sent, then it doesn't comply with the implementation guide.
If the element is situational, of the second type, and the situation is false, and the element is not sent, it complies with the implementation guide.
All of these options -- there are, I think, 12 options -- make the implementation more difficult, and I would say could lead to confusion if that other fundamental tenet of ignore what you don't need is not used.
I marked on this slide five little thunderbolts of problematic situations. These are the five little thunderbolts, if you look at the picture, is everywhere that it says that the transaction does not comply with the implementation guide.
The reason for that is because I think there should be a fifth column that says, what should be the receiver action.
The receiver action is that, whenever there is an element that is not compliant with the implementation guide, if you are not going to use that element, you should not reject. You should just ignore it.
Otherwise, you are forcing the sender to be unduly picky about what they send. So, I have some recommendations there as to what to do.
So, my recommendations for the subcommittee today, I bring four recommendations. The first is flexibility in implementation. Five recommendations. The first is flexibility in implementation.
There should be explicit instructions from HHS and the upcoming transaction rule next year, so that the receiver of a transaction that contains or lacks data that is not used by the receiver will not be required to reject the transaction back to the submitter, and will not be found in violation for having processed such a transaction.
Let's say that I am a payer and I say, send taxonomy codes only when doing work in a rural clinic, and I get taxonomy codes from a provider that is downtown.
The implementation guide clearly says that the situation is not present, that the element should not be sent. What harm is done by sending that element.
As a payer, I should be allowed to accept the claim and ignore the element, and not to be considered in violation of HIPAA. This is to try to make it easy.
My second recommendation is that receivers of the HIPAA transactions must be ready before the senders of the transactions are ready.
In general, the clearinghouses and payers have to be ready before the providers can send. So, there should be some sort of regulatory requirements for receivers to be ready at least one or two years before the senders are required to cease using the current version.
So, the recommendation comes in this form. Provide at least two years overlap with the current standards for the implementation of the new standards.
For example, the receivers and the senders would be required to be capable of receiving or sending the new standards by January 1, 2008 -- I just pulled this out of the hat, just for the example.
By January 1, 2008, they have to be able to transact with the new standards. Then they are given until January 1, 2010 to discontinue sending the current 004010-A-1.
So, there are two years for the transition. That is very important. That is being done today with these infamous extensions or contingency periods, but it is a fundamental thing that we are going to have to do this.
The third recommendation, I would like HHS to provide specific technical assistance, specific to have a library of reference transactions in compliance with the new HIPAA guides, that both receivers can use to test their systems, and senders can use as a model as to what should be in those transactions.
This should be a very easy project for HHS to do or fund. In the past, WEDI tried to do this with the 004010 transactions and, because of all the volunteer effort and everything else that was going on, we never could get it off the ground.
We got the A37 professional and there is only one set of examples of the A37 professional. Now, there are some commercial sources of examples for this, and I think HHS should fund some examples, in fact, a very extensive library of reference examples for the industry to pull from.
They should represent all transaction sets with multiple business scenarios, and should be useful for checking boundary conditions, loop repeats, and so on.
Today is the day when there is a good number of companion guides that say, if you send me a claim, if it is a professional claim, I don't want more than six service lines, never mind that HIPAA requires 99 service lines.
There are very large payers that say, don't send me more than six, or don't send me more than 15 service lines. HIPAA requires 99. Those boundary conditions have to be changed.
Recommendation number four, HHS to endorse the existing X12-N TG2 interpretations portal, and give it formal authority to interpret the HIPAA guides.
Right now, that interpretations portal is a voluntary effort by the industry and it has no authority. HHS should give it formal authority, and any interpretations coming out of the portal should be considered as the official interpretation of that problem in the guide.
Finally, my fifth recommendation is to provide a process and a framework for subsequent migration to newer versions on a regular cycle, every two to four years, without having to involve the regulatory process.
This would also include the overlapping of implementations and stating of new versions, like I described in my second recommendation.
You are going to hear today, and you heard yesterday, about whether the decimal or non-decimal, or with a common period with X12 and NCPDP is sufficient. I am not going to get into that.
What I clearly want to get into is that there has to be a process that doesn't involve an NPRM every time there is a change to a version. With that, I will stop there, and leave the rest of the time for the other panelists.
MR. REYNOLDS: Thank you, Kepa. We will hear from all the panelists, and then we will open the floor for questions. So, Don, please?
Agenda Item: The Vendor Perspective.
MR. BECHTEL: Thank you, Harry, and fellow committee members. My name is Don Bechtel. I work with Siemens Medical Solutions Health Care Services, where my responsibilities include standards and regulatory management and HIPAA compliance, specifically for X12 transaction standards related to the regulations for code sets, identifiers, security and privacy.
I would like to thank you for the opportunity to share with you today the views of Siemens on this increasingly important topic of updating the HPIAA standards.
As a little background, Siemens medical solutions, of Siemens AG, is headquartered in Malvern, Pennsylvania and Erlangen, Germany.
We are one of the largest suppliers to the health care industry in the world. The company is known for bringing together innovative medical technologies, health care information systems, management consulting, and support services to help customers achieve tangible, sustainable, clinical and financial outcomes. Siemens Medical employs approximately 31,000 people worldwide, and operates in more than 120 counties.
A little bit also about our commitment to standards, Siemens is actively supporting the development of many standards development organizations and consortia, including HL7, ASTM, Dicom, X12, IHE and others.
We currently have 75 people who are actively working on the development and maintenance of standards in these SDOs and committees.
Our commitment to the standards is based on the premise that we believe standards improve our products' usefulness to our customers, and help to ensure that we are meeting interoperability requirements that are increasingly important in our industry today.
Interoperability has many faces in health care systems and technology, and the National Alliance for Health Information Technology.
NAHIT's definition of interoperability is the ability to differentiate information technology systems and software applications to communicate, to exchange data accurately, effectively and consistently, and to use the information that has been exchanged.
The term interoperability in the collaborative, ONCHIT, our fee responses have three distinct components, each of which must be present to enable full participation.
Without reading these definitions that are in my written text, they briefly are, the IT network, access level, network authentication level, and what is more important to the HIPAA transactions, the application level.
Through the use of standards, achieving interoperability in health information technology has occurred within and among the systems of health care stakeholders.
The transfer of information has occurred among various systems found in hospital settings and large, integrated delivery networks, or IDNs.
Many of these systems are from a variety of vendors, yet they must all integrate into seamless access to a patient's data in the entity's health care environment.
With today's health care initiatives from the office of the national coordinator for health information technology, or ONC, the industry is now focused on moving outside of the IDNs, into broader integration requirements, to disseminate health information through regional health information organizations, and ultimately to a national health information network.
It is for these reasons that Siemens is extremely interested in the use of standards today. HIPAA is part of this, and HIPAA is a primary building block for these external interfaces and interoperability between the health care operational entities exchanging health information among providers, health plans, pharmacy benefit managers, clearinghouses, and others.
As a key component to HIPAA interoperability is to ensure that the data content and the standards used to exchange health information is accurate, consistent with industry needs, and is used with all entities with whom the data is shared, however, if this information is to remain useful toward the goal of improving the quality of health care, it must also remain current with industry improvements and provide support for changing industry needs, such as ICD-X coding systems, which will provide more specific and complete medical diagnosis and procedural health information.
To acquire these improvements, we must be able to upgrade our standards to newer versions as they are developed by the SDOs, for example X12 or NCPDP, that would include enhancements needed to support ICD-X or other similar requirements.
It is important to Siemens customers, and we, Siemens, and other vendors, utilize industry standards for quality data and information exchanges among many systems they operate in their health care environment, among the business partners they exchange information with, including the health plans, state and federal public health agencies, and so on.
This requires that our customers remain current with the standards that are developed by the relevant SDOs, and that the industry implement these standards to support these various quality and health care initiatives.
Consequently, vendors are required by our customers to support relevant standards and regulations. As vendors, we are also interested in improving work flows that provide the fullest benefit of the standards to our customers by providing improved efficiency and effectiveness, which is good for health care, and also helps to sell our products.
For EDI, implementing transaction standards has value to the customers, and requires that all industry stakeholders, providers, health plans, clearinghouses, support the use of the standards.
Otherwise, the benefits are never fully realized. To this end, regulations help to ensure that everyone is participating.
However, regular updates must also be supported to ensure that the industry needs are continually being met on a timely basis, and will also help to eliminate extensive cumulative changes.
Unfortunately, for the HIPAA transaction standards, it has not been our experience that these things happen. The transaction standards continue to be modified by the SDOs to meet the industry needs, but adoption of these newer versions by the industry has not occurred and has negative consequences to our customers and the industry's effectiveness overall.
One such consequence is the loss of opportunity to utilize improved standards for critical HIPAA transactions that would realize a return on investment or quality improvements.
For example, consider claims or remittance transactions, which were available in X12's version 004010, but were never adopted.
X12 is now working on version 005010, which should be ready for adoption by the Department of Health and Human Services late next year, and promises to being even more improvements.
Version 005010 will also bring a larger set of changes. Because it is inclusive of all changes since version 004010-A-1, implementing version 005010 from our current version 004010-A-1 will require more application development work to support the standards, and will likely require longer implementation time for the industry.
This could extend the transitional phase for dual processing for many affected stakeholders until full implementation can be achieved, which impacts everyone's overall efficiency.
Another interesting point about regulations is some regulators have indicated, during a recent claims attachment conference, that they will not implement new standards that require legislative actions, such as those controlled by HIPAA, until there is a final rule.
Their explanation is that they don't want to develop systems enhancements that can't be implemented by our customers.
In other words, with HIPAA, legislation is required for entities to utilize newer versions of the adopted standard.
Without the necessary legislation, many entities won't move forward to the newer version of the standard. So, exchanging the newer versions is problematic if everyone is not participating.
Additionally, few vendors are willing to be early adopters in a trial use program, because there is no guarantee that the interim version will ever be adopted.
This raises the potential risk that the vendor's development efforts would have a negative profit impact, and software would be unusable to the vendor's overall customer base.
It is important to both the industry and vendors that we have more frequent and timely, predictable, consistent delivery and adoption of new versions of HIPAA standards.
Frequent updates will allow for smaller and more manageable changes, which are more easily accommodated in regular software updates.
This is less expensive to develop, normally easier to implement, and has less overall industry impact. Yet, at the same time, it increases the efficiency of the industry incrementally.
We are in a business environment where products must routinely be updated to keep pace for demand for change and work flow improvements to take advantage of new innovations, technologies, and industry initiative -- for example, those from ONC -- which would lead to better quality, faster access, less human intervention.
Software updates need to be smaller and more manageable, so we can continually adapt to a changing environment.
Unpredictable changes that take years to adopt tend to be much larger in scope and more difficult to integrate into our products, taking more time and effort to develop and validate, leading to longer development and implementation cycles that are not cost effective, and tend to be disruptive to all stakeholders who must implement them.
While the industry waits for changes that are slow to be adopted from the federal process, which currently can take four or more years, organizations are often forced to take other measures.
These are often proprietary in nature, and only meet individual requirements, not those of the industry. This approach is temporary and must later be undone when standards are adopted. Consequently, vendor support for such solutions is impractical and costly.
Additionally, vendors and the industry would greatly benefit from a two to three year road map from the standards development organizations, work that would be completed by the SDOs, or could be completed by the SDO and harmonized collaboratively by the SDOs via the health information technology standards panel, or HITSP.
Such road maps would allow vendors and other stakeholders to better plan and budget product development work and implementation schedules to accommodate these changes accordingly.
The industry also needs some assurance that the Department of Health and Human Services will actually adopt these new standards, so the industry will actually implement the enhancements.
Without this assurance, they will continue to experience slow reactions to important industry requirements, such as those which we have seen with ICD-X.
The current adoption process for new versions of HIPAA transaction standards, as you will later hear from the testimonies from X12 and NCPDP, are currently slow and redundant, of activities that were already conducted by the SDOs.
The federal process for adopting revised HIPAA transaction standards needs to be revised to eliminate redundant comment periods during the notice of public rule making, and to publish notifications in the Federal Register when the SDO is conducting a comment period on an adopted HIPAA standard.
This change may require legislative changes to permit the process modification such as this, but such a process change would greatly reduce the adoption time for new versions of the HIPAA standard, and would enable more incremental adoption.
Such a process change would also allow the industry to more quickly utilize new technologies and innovations that are being adopted or required.
In summary, I have five recommendations that I have kind of made throughout the reading, and I quickly will summarize those.
First, the HIPAA standards should continue to be regulated, but process improvements are necessary to accomplish the goal of administrative simplification.
Second, we need frequent and predictable updates to the HIPAA adopted standards, that are available on a two to three-year cycle, or perhaps yearly, if each year alternating standards are modified.
At least every three years, all standards should be refreshed to the most appropriate standard version, as identified by the SDOs and the designated standards maintenance organizations.
We need a less redundant federal process that does not include an NPRM step to modify the rules of the HIPAA standards that have already been adopted and maintained by an ANSI accredited SDO, where a transparent process is used, and is open to the public, and includes public comments and required SDO responses.
Fifth, we need the Department of Health and Human Services to post notices in the Federal Register to indicate when an SDO is scheduling a public comment period for a standard that has been previously adopted under HIPAA.
Again, I thank you for the opportunity to allow Siemens to present to you our comments, and I would be happy to make myself available for any additional questions that you might have. My contact information is below.
MR. REYNOLDS: Thank you, Don. John?
Agenda Item: The Vendor Perspective.
MR. HAWKINS: Good morning, Mr. Co-Chairmen, members of the subcommittee and staff, I am happy to be here to discuss items pertinent to the updating of the HIPAA standards.
I am John Hawkins. I have been in the health care industry, both on the provider and vendor side, for over 30 years, and I am currently a product manager with Quadramed, with responsibilities for HIPAA, including the transactions, and all of the things attached with the rolling out and complying with HIPAA.
Quadramed is a company located in Reston, Virginia. It provides health care information technology for both hospital information and health information management systems.
Today, I am representing the Association for Electronic Health Care Transactions, AFEHCT. AFEHCT is a health care IT vendor industry action group, with a focus on federal public policy as it relates to the application of EDI, e commerce, the internet and health care IT software, to solutional problems associated with delivery, financing, administration of health care, in both the public and private sectors.
It, in fact, represents billing, services, practice management systems, patient account revenue cycle management systems, clearinghouses, hospital information systems, electronic medical records systems, vendors that work with Medicaid, and vendors of translation mapping, and integration brokers.
Representing the vendors today, I want to speak a little bit on how changes to existing methods used to implement new versions of the transaction and code sets, how those changes could be made to allow the process to be more responsive.
As HIPAA truly does become a mainstream part of health care organization operations, it is common now to go into an organization, see them doing the electronic eligibility checking as part of registration, see them electronically submitting all the claims using the A37.
So, truly, the first hurdle has been achieved, and that is bringing the transactions into a level of day to day operation.
As the transaction and code sets, though, have been implemented, it has become evident that the test of day to day operations has surfaced some deficiencies in the initial implementation, as an industry that efficiencies are addressed through the appropriate standards organizations or SDOs.
The issue now, as has been mentioned earlier, is the length of time it is taking to get those changes adopted into the industry and implemented, in particular, moving to 004010 or eventually 005010 when it is adopted by DHHS in 2006.
There are many things that have surfaced when trying to do eligibility, for example, where you cannot take full advantage of the reply because there are some structural things within the message itself that are being addressed in future versions.
The problem is that we are having to live with the existing version for years before we can get to the newer versions that will address making the EDI and HIPAA more pertinent to day to day operations within the facilities.
Today, the designated standards maintenance organization, DSMO, reviews the requests for changes. Then it is forwarded to this committee, to NCVHS.
There are hearings held, like today, and then recommendations are sent to the Department of Health and Human Services, to adopt a newer version.
DHHS commences a federal rule making process, which includes a notice of proposed rule making, and finally the issuance of a final rule that would also indicate the compliance state.
It is this process that has led to today's situation where the SDOs have made changes to the standards to meet new industry needs that have been identified, but adoption of those newer versions have not occurred.
It is the federal process, and specifically the NPRM process, that AFECHT wishes to comment on. AFECHT's position is that the SDO and their processes represent a responsive means to assess change requests, provide industry comment opportunities, and formulate timely decisions and providing solutions that will support the continued evolution of HIPAA.
AFECHT proposes that the SDO standards development process, which includes a public comment period and SDO response to those comments, should be adequate to meet the federal requirements as outlined in federal HIPAA law, to bring forward modifications to standards that have already been adopted by HIPAA without requiring an additional public comment period by way of the NPRM.
DHHS should issue a final rule change to the adopted HIPAA standards, that would change the reference to the implementation specifications, or the implementation guides, to those that represent the newer versions of the standards that were recommended for adoption by the SDO and DSMO.
The SDO process is open to the public during the development and comment period for all proposed changes. AFECHT also proposes that notices be placed in the Federal Register announcing when an SDO is conducting a public comment period, so that notifications are consistent with other changes to HIPAA and made available to the same audience who currently monitors the Federal Register for such announcements regarding regulatory changes.
Making this change will expedite the implementation of modifications already agreed upon by the SDOs, that will eliminate a redundant comment period, one by the SDO and one by the NPRM.
It will remove the opportunity of getting into a cycle of commenting and going back and commenting and going back, which just prolongs the implementation of any new versions.
For efficiency's stake, having a single comment period will speed up the process, and should provide an efficient way to move forward.
Another effect of this change to the industry will be to determine the impact of making change, and establish an industry-driven consensus through the DMO for the frequency of change.
I think we can figure out, once we go through this, can we take it on every year, every three years, what is the right thing.
It is important to vendors that changes be manageable and predictable. Having smaller and more frequent updates will make it easier for us to provide to our customers those changes in regular software releases, and not incur both a burden on the vendor and the provider, to take special releases to remain compliant with HIPAA.
This will also serve to improve the adoption rate of these changes, as the software that would comply with the new regulations will be made available to the clients in a quicker fashion.
It seems likely that the industry could accommodate changes on a two to three-year cycle, and have some predictability, but would also allow us as vendors to better plan our efforts for maintaining HIPAA compliance. As Don mentioned, you get into things of your budget, and things you need to do to provide value to your customers as a vendor, and you have to work that in with complying with the regulations as well.
AFECHT's position is, HIPAA has established the transaction and code sets, such as the 270, 271, the A37, and the industry, through the SDOs, should be able to determine the versioning of those transactions and the migration time lines moving forward.
AFECHT also believes that, while certain levels of backward compatibility are necessary at the core of the transaction sets, the migration to future transaction set versions should occur at the version level, and that software should help with the staggered option time lines of the new versions, again as Don mentioned, with some phase-in period.
In summary, a number of recommendations. Eliminate the NPRM process for changing versions. Move the authority for making the changes to the existing HIPAA standards to the SDOs.
Have DHHS post notices in the Federal Register, with a public comment period when a previously adopted standard is going to occur.
Streamline the comment process by allowing the use of a public comment period and responses, already in place at the SDO, to meet HIPAA requirements.
By allowing the SDOs the ability to react to changes in a timely way, and to implement improvements in the transaction sets sooner, the realization of the vision of HIPAA for true administrative simplification through automation, supported by standardization, will occur more quickly. Thank you for the opportunity to speak with you today on behalf of AFECHT and the vendor community.
MR. REYNOLDS: Thanks to all of you, a lot of good stuff to think about. We are going to have about 30 minutes worth of questions. So, I will open it to the committee and staff first.
Agenda Item: Questions and Answers.
DR. FITZMAURICE: Two questions for Kepa. On the next-to-last slide, recommendation number two, provide at least two years of overlap.
On the second bullet, you say senders should be required to be capable of sending the new 005010 transactions in production by 2008, but not required to discontinue sending the old one by 2010.
So, you would hold the providers to the same requirement as the receivers, have your systems ready to send it, but you don't have to search around for maybe extra variables for two more years.
Why not give them another year or two to be capable of sending those transactions? Say they could do it January 1, 2008 if they want to, but why the difference between having them at the same time as receivers versus say two years later when they have to discontinue it.
DR. ZUBELDIA: Michael, that is an excellent question. When I was putting those bullets together, I went back and forth between the two concepts.
The problem is that, if the receivers are required to receive the transactions by, say, 2008, but there is nobody to send them --
DR. FITZMAURICE: Maybe, it s voluntary, could be voluntary.
MR. ZUBELDIA: It won't work. You have to have -- it is not one of those situations where you will build it and they will come. You build it and they won't come, and we have seen that through the HIPAA process.
I think that you have to have a requirement, probably unenforceable, that the senders be ready to send by that date, but they have two years to transition. It is more a moral requirement.
DR. FITZMAURICE: I accept your analysis of it. The second question, recommendation number four, HHS is to endorse the existing interpretations portal, give it formal authority to interpret the HIPAA guides.
A question, then is the government to enforce what the interpretations portal makes formal. Probably yes. Is this equivalent to like giving JACHO deemed status to credit hospitals? You would ask the government to give the interpretations portal deemed status to formally interpret the HIPAA guides.
DR. ZUBELDIA: Exactly. There is a problem today where sometimes the interpretations portal will say something where HHS, through an FAQ or a program memorandum or something has given an instruction that is contrary to what the industry understands and what the interpretation guide portal is saying. I think there has to be one source of interpretations.
DR. FITZMAURICE: So, the government would have to have an accreditation process to accredit this interpretations portal.
I mean, the government has done this before in other places before and will continue to do it. It is making that link between government police and somebody who interprets what government policy is, and then the government is supposed to enforce it.
DR. ZUBELDIA: I am not sure about the government having an accreditation process for the interpretation portal.
The government is supposed to adopt industry standards. Let the industry define the standards. What is happening today is that the industry has defined the standards, and now the government has an additional layer on top of that, sometimes with interpretations and technical issues that are standards issues that the industry should be interpreting.
So, I think there has to be that separation. Let the industry define, with the interpretations portal, what the issued resolution is, and the government adopts that, along with the standards.
DR. FITZMAURICE: I understand what you are saying. I just see some problems. One last question for John Hawkins, Quadramed.
I was pleased to hear the testimony of all three of you. I think it is courageous and time consuming to get up here and inform us of things that you already know, but it is essential for us to understand it, and you have really helped with that essential-ness. Is essential-ness a word?
On AFECHT's recommendations -- I am looking at page four of the bullets -- move the authority to make changes to the existing HIPAA standards to the SDOs.
Again, I have the same kind of question of enforcement. So, you would have SDOs make changes to the standards, and then the government enforce it. I think that would be required by HIPAA, without going through a government process, although if they are accredited they have open public processes.
That is essentially the way you would have it work, that the SDOs make the changes, the government enforces the timing and the implementation of those changes?
MR. HAWKINS: Yes, I think there would be some working in concert there, but the key, I think, is to try and reduce the redundancy on the comment periods, and let the industry folks, who can get the standards out with the comment periods, taking all of that into account, drive the adoption of when those new standards could be done.
As Don mentioned in his comments, there needs to be some regulatory envelope around that, so that we, as vendors, can go to our people that we are responsible for and say, there is a regulation with this date, we need resources to meet it, so that we can then develop those solutions and get them out.
DR. FITZMAURICE: I see this not only as breaking a log jam of time delay, but also sharing more power with the industry to set the standards, and then, to take Kepa's suggestion, sharing the interpretation with the industry.
MR. HAWKINS: Yes.
DR. FITZMAURICE: Thanks for helping with that understanding.
DR. STEINDEL: Thank you, and I would like to thank the panel for this very informative discussion. One general question to the panel, which I will come to second, but the first question is on Kepa's very nice introduction on EDI and the way it works in the world outside of HIPAA.
What is interesting about this is, from my understanding -- and this is in a previous life as working for an EDI vendor for software -- there are some 800 pound gorillas in the EDI world that say, this is the way we want these sent.
We know of one in Benton, Arkansas. We know another group that comes together in the automobile industry, where we don't have this clear implementation guide.
The implementation guide as the 800 pound gorilla says, this is the way you will send it to us. Applying that analogy into the world that we are dealing with, we have a couple of 800-pound gorillas. We have one real 800 pound gorilla and maybe one or two 400 pound gorillas in the health care industry. What are your comments about the health care industry operating like the EDI industry really operates?
DR. ZUBELDIA: Steve, it is great, because the Walmart analogy comes up all the time and GM has the same situation.
The problem is that we don't have an 800 pound gorilla. We have -- I am not going to use animal analogies -- but we have more like a zoo.
Each, maybe, care contractor has different ways of implementing the HIPAA transactions. So, it is not one maybe care way of doing things. There is a multitude of them.
If there was one way to do it, the vendors would immediately rally behind that way and just implement it that way for everybody else, too, but there is a multitude of ways. Minor tweaks, minor differences, and that is a problem.
DR. STEINDEL: Can I interpret that as maybe another solution would be to eliminate the minor tweaks?
DR. ZUBELDIA: That would be great.
DR. STEINDEL: But that is outside of the HIPAA process.
DR. ZUBELDIA: Claredi has had the convergence project going on for over a year. We have identified over 1,200 companion guides, I reported to the NCVHS a few months ago, and we don't see a reduction in the number of guides.
DR. STEINDEL: Thank you, Kepa. Now, my question in general to the panel -- and I really appreciated the way -- Kepa was a little bit more indirect on this, but basically was saying the same thing -- we are talking about eliminating the NPRM process.
In response to Mike's comments, the way I was thinking it would work, is that the SDOs would go through their comment period, it would be announced, et cetera, comments would be received, it would be finalized.
The way it would be made -- quote, unquote -- legitimate is that we would eliminate the NPRM and just issue a final rule.
That is where we get into the adjudication that John had mentioned earlier, et cetera. I think we would cover both bases.
The one thing -- and I liked the way the three of you alluded to the words in the legislation that basically said the SDOs are the drivers of this process, and that we should give the process back to the SDOs and eliminate the NPRM. At least that is the way that I interpreted it.
There is only one thing that is in the middle of this that was not mentioned, and I want your reactions to that.
The law also gave this committee responsibilities to review and report to the Secretary on that. Would you see that happening during the SDO comment period, once it is formally announced that the SDO is asking for comments on this version, that is when the NCVHS would start taking a look and giving its advice to the Secretary? Would that be your interpretation? None of you mentioned this.
MR. BECHTEL: In all of the process that I have had on this topic -- and I have also been involved in X12, I co-chaired a health care task group and we discussed these things many times, and I have also, as you probably know, been involved with Nancy Johnson's bill, 1457, that is addressing some of these legislative changes.
It has always been, in my understanding and thinking, that NCVHS would continue to be involved in the process.
The process would be the SDOs, who would do the work, do the commenting. The assumption is that the government can be part of that commenting period, or also part of the development process. They are not excluded and they do participate.
If we could get the notification and public comments out to the general public, you could have -- and we do that today in X12, it is not that we are not doing general public announcements, we are, but we are not getting the benefit of the Federal Register, which probably reaches even more people than we are capable of, because some people are only paying attention to the Federal Register.
We would still see this eventually coming forward to the DSMO to review and make sure we have no issues among the SDOs, and then coming here for review on the impact on industry and the kinds of things that you would want to review before you make a recommendation. So, in my thought process,I have always continued to see NCVHS' role continued in the process.
DR. ZUBELDIA: I would like to make a comment on that. I think that the NCVHS would play a very important role.
The SDOs would define the standard to be adopted, and the version and so on, and the data content. There is no need for any additional comment period on the content of the standard.
There has to be a finality date, an effective date for that standard. I think that is where the NCVHS could recommend to the Secretary, that this standard be adopted effective with this date, and that this other standard be retired effective with this other date.
It could be expressed in the form of a two-inch column in the Federal Register that says that the industry standards for HIPAA transactions have been migrated to this version, effective this date, end of story.
There is no need for a 300-page proposed rule. At that point, the industry would have a finality, it would be an enforceable date, everybody would know what the dates are.
I would use the standard process that we have followed in industry for years before HIPAA, which was, you have the current version and either one or two prior versions always in place and, as you move, you have a window of the current, plus one or two, that you are moving along.
That is enforceable with an effective date, and a termination date for the older standards. That would be a very simple process, and I don't think it would require a big notice of proposed rule making process.
DR. WARREN: My question really was I guess mostly answered by Steve's last question about this new proposed process.
In your testimony, especially in the testimony you gave us, John, you said you wanted the NPRM process replaced by the SDO, but you didn't talk about any of the other process, although you, Don, did comment on how you thought the process might be different.
I would like to hear more and maybe even a written proposal from one or all of you on what you would like to see this new process look like.
You did a nice delineation of the current process, and then stopped with that. I think it would make it easier for us to understand exactly what you would like us to consider.
With that, I guess I would like John to respond first. When you outlined the current process, could you outline the process you would like to see if the NPRM is replaced by the SDO and announcement in the Federal Register.
MR. HAWKINS: And I will let these other gentlemen jump in also. I think there is a period where you make the comments and it goes through the SDO, you get approval, you go back again and you go through another approval process.
I think, to some extent -- and I am not trying to over-simplify it -- just remove the one process and pretty much let the rest of the processes go as they have been going.
Assume that the approval is the comment period for the SDO. Then come back into the process where you would have come back into the process once the NPRM comment period had gone on and move through.
DR. WARREN: Actually, what I wanted to hear you say that. .When you were giving the testimony and I was reading it, that is what I thought was happening.
Then, as more questions were being asked, I thought, well, I had better clarify what I think I am hearing.
MR. BECHTEL: I think John has summarized that fairly consistent with what I would say. I was going to offer, I have put together some process documents while working with Nancy Johnson's staff that, if you are interested, I would be willing to share with you, if you would like to see those.
At least it would outline how we thought about it, and it does go into detail about what happens where. I would be willing to share that.
DR. WARREN: That would be very helpful in us coming to grips with this.
MR. BECHTEL: I know that X12 and NCPDP are also going to talk on this topic. So, you are going to hear a lot more about some of the thoughts.
DR. COHEN: Thank you all for being here, and obviously, Kepa, it is great to see you again. Obviously, we have been talking about, I think, simplification of the process, and I think we are all very supportive of ways to streamline the process that I think has sort of evolved over the last couple of years around HIPAA.
When we talked about this previously, I believe we have all been struck that, whereas the industry has come forward to talk about simplification, there has been difficulty in terms of coming down to actually agreement on what that simplification means.
Now, obviously, you have come forward, and I understand at a high level what you are describing. I would love to see Don's more detailed version to see really how this all works.
I was intrigued, and I just wanted to ask all of your opinions on the process that was brought forward by the federal government in the final rule of prescribing.
This is obviously in the preamble to the regulation, where they are describing a process relating to e prescribing rules around backward compatibility in terms of potentially at the secretarial discretion, not requiring the full NPRM process, and basically being able to sort of move forward relatively rapidly.
I know that was something we were discussing yesterday, and request from the NCPDP to move from version 5.0 to 8.1.
It appears that it may be able to be done relatively quickly in a very streamlined fashion. Now, obviously that does require this sort of concept of backward compatibility, and minor rather than major changes, the major changes still having to go through some sort of a regulation process, I think, was the thought.
Obviously, this may work for some standards, may not work for others, but I am curious about what your views of something like that is, and just sort of putting it on for a second to see how it might work for the HIPAA transactions. Kepa, do you want to start out, and then maybe Don and John?
DR. ZUBELDIA: Simon, I am not familiar enough with the e prescribing process, how it would work for our transactions.
The backward compatibility requirement would be problematic. The X12 transactions are mostly compatible, but they are not backward compatible. So, that could be problematic.
MR. BECHTEL: I would share that comment. First, I am not really familiar with NCPDP's process. So, I am not sure I could comment on it.
I am concerned about backward compatibility as a way to eliminate the NPRM process, because I personally feel many of the standards, as we move them to new versions, will not be backward compatible as the definition is defined.
Backward compatible is sort of something -- I understand what the concept means, but I don't understand how the concept would be applied.
I think what we really need to do is, when we have a new version, really use the new version, and continue to use the old version and transition until we get to the new version.
Having somebody send an old version to somebody who is only receiving 005010s, and somehow be able to process a 004010 with 005010 software, doesn't make any sense to me.
That is not the way the programming is done. That is not the way the systems work. So, I am sort of under the opinion that we need to have transitional periods to get from one version to the next.
We probably need to allow both versions of the standard, two versions or maybe as Kepa said, three versions running at all times, but always moving forward, and eventually sunsetting the oldest one and keeping that process working.
This allows different participants in the industry to make the migration and get to where they need to be in a reasonable period of time.
It also means you are running dual systems. I am sure the industry doesn't want to be running dual systems for long periods of time either.
I think there is something that has to be worked out here, but I really don't understand how backward compatibility achieves that. I think you will have a dual process, and that is what we need to focus on. That is just my opinion.
MR. HAWKINS: I would agree with everything that has been said, and I think part of the solution is the software itself.
When you are developing the 005010, you are going to develop it to be in compliance with that implementation guide. You have already got the 004010-A-1.
So, then the software can control -- well, Blue Cross, 005010, once they are ready, Equitable doesn't because they are not. So, you do have these dual processes going on but they are done, if you will, in big chunks. It is the whole version.
Blue Cross gets 005010, Equitable gets 004010. Then you manage that migration over time as the payers and clearinghouses evolve to accept the newer versions.
When it is in software, you just make changes that say, okay, now as of today, WebMD can accept 005010, so we are going to start outputting the A37 and 005010 version, and do it that way.
Part of what I am hopeful for is that there are significant enough changes in the newer versions to fix some of the issues that have arisen, that we don't want to keep living with the problems we have got. Let's fix them and move on. Usually the easiest way is just to adopt a new version and go forward, I think.
DR. COHN: I appreciate all your comments. Obviously, I am obviously representing the process. Once again, Kepa, this is not NCPDP process. This is a Federal Register or governmental process.
So, you all might want to take a look at the e prescribing final rules, just to think what you can -- just to see how it all fits and whether it even could fit and how it might be applicable, because it is trying to segregate the big changes from the small changes.
It is just another approach. Of course, the other issue is that, in some ways, it depends on how you -- you know, you architect changes to standards, and there are various ways to sort of segregate new from old.
I mean, HL7 was able to do sort of backward compatibility through most of its 2.X family. I think it is a question of how one approaches new standard versions, but it is just something to look at.
MR. ZUBELDIA: Simon, just as a suggestion, NCPDP is obviously familiar with the e prescribing process, and I believe that they have recommended that, for the HIPAA transactions, there should be specific changes such as no NPRM and perhaps even no DSMO process.
So, you may want to listen to what NCPDP has to say about that, rather than us, who are not so familiar with that.
MS. BURKE-BEBE: Two things that I wanted to comment on were actually comments on by Judy and by Simon. In reference to the NCPDP information that we received yesterday, one thing that I will remind us is that neither the 5.0 or the 8.1, we were told, are even in place. So, it is not the same as if one was and then the backward compatibility.
Judy, your recommendation to actually see a proposal, I think, is an excellent one. I am not quite sure I understand yet the layers of NCVHS and even the DSMO process and, that being kept, how it would still reduce the time element to implementation. So, I would like to see that.
MR. BLAIR: I wanted to thank the panelists for the work they have done to try to think through this effort. I think it is intriguing that the recommendations that appear to be coming forward.
They don't seem to be half measures, but wholes measures. The idea of eliminating NPRMs, in total, seems to be what I am hearing.
If I start to think about that, I see why there is a very compelling case to do that for those SDOs which are ANSI accredited and comply with the ANSI consensus based process.
So, I have two questions, and why don't I do them bit by bit. My first question is, that if the world changes and we don't have an NPRM process for new versions of health care IT standards, would there be a criteria that the SDO that comes forward is ANSI accredited and follows the ANSI accreditation process, the accreditation process?
MR. ZUBELDIA: Oh, absolutely. I think we would run into a big risk in eliminating the NPRM process for other things, for instance, a switch from ICD-IX to ICD-X, or the upcoming plan identifier. There has to be an NPRM process for those.
For these standards that are going through an ANSI accredited organization that, by the ANSI rules, has to have an open process and has to have an open public review period, I think that is a completely different world.
MR. BLAIR: Don, do you feel the same way?
MR. BECHTEL: I would agree that we need to have, for this process, an ANSI accredited process, to sort of be a prerequisite to eliminate the NPRM.
I am kind of thinking, though, as you asked the question, could we eventually have standards that are not part of necessarily American standards that we are using, but international standards that we are using.
What certification process or accreditation process would we look to then. I don't know if there is an ISO accreditation that one would refer to or not.
Maybe what that says is, if we had standards that were in that space, they would have to continue to use an NPRM process, because we would have no other way to get public comment on them.
I think in terms of the SDOs that are involved with HIPAA today, these are all ANSI accredited standards, and I think it would work.
MR. BLAIR: My next question, then, is actually closely related to this first issue. One was, you know, the proposal -- well, let me step back so I get this in the logical path.
The proposal is to replace the NPRM process with the process that the SDOs already use when they get ANSI accreditation for that particular standard.
One of the things that your response was that yes, they have to go through that consensus based ANSI process in order to be part of this.
The other piece is, increasingly, we need interoperability among standards, which is standards harmonization.
So, I find it difficult to take this first step to say, okay, we don't need an NPRM unless I have a little bit better understanding about what we might recommend in terms of standard harmonization. Could you give us your thoughts or guidance on that?
MR. HAWKINS: Perhaps one example. One of the things that we are living with, and Kepa mentioned it, about certain companion guides dictate certain rules that perhaps are contrary, but within the general umbrella of HIPAA, and I will pull one out in particular.
MediCal has said, for a particular setting, there will only be one line item on a claim. That is contrary to everything in the HIPAA regulations, and in the current version, but it is within a gray enough area that they can do that.
I think part of the process is, we want to be able to address those kinds of things, get them into future versions or some kind of releases, so that, as these things come up and we address them and we want to get to standards, we can stop those kinds of things or work with them, to come up with a reasonable solution, and then put that out in the next version or some way of moving that forward to minimize some of the companion guides, and to try to streamline the system to where it is truly standards and not medicare and 50 medicaids the payers.
MR. BECHTEL: I guess I would also like to comment. On the question of harmonization -- and I assume you meant harmonization across different standards between NCPDP or HL7 or someplace else -- I think we need to reflect on what HITSP, or the health information technology standards panel, is going to do.
From this organization, all the SDOs are joining to participate in that. More than just the ANSI accredited SDOs, there are non-ANSI accredited SDOs participating in the harmonization process at HITSP.
The SDOs are going to have to find a way to respond to AHIC and the direction that they are being given that will come to the use case committee, which is being run by HISTP.
The use case committee is likely to define what standards are used to do what parts or pieces of a use case, and then we have to have harmonization and fill the gaps where we have gaps in that process.
I think all of that is going to begin to happen through that process, and again, ANSI is driving that. So, it will be an open process that will having voting as well.
DR. HUFF: So, a couple of things. Just at a high scale, to make sure I understand this, there would -- sort of starting at the top, the assumption would be that, for bringing whole new areas of standardization under regulation, it would probably require legislation.
If we are doing major changes, adoption of new transaction types, other things, we would go through the NPRM process, or if we were doing ICD-IX to ICD-X, that would go through an NPRM process.
If we are doing version changes within an adopted transaction, then we would have this more streamlined SDO driven process. Is that a fair summary?
MR. BECHTEL: That would be my concept.
DR. HUFF: Great. Then a second point, you have been talking about, and using the words, comment period during SDOs.
Now, it may be different in other places, but in HL7 it is really a ballot cycle, for instance, is what it really is. It is not a comment period. There is a ballot period.
Is that -- are you equating the ballot process to this comment period in the SDO, or is there something different that happens in X12. How does that work in X12?
MR. BECHTEL: In X12, it is different. We also have ballots. We go through a balloting process on new standards or changes to standards that are made, which is basically done by the membership of X12.
The public comment period that I am referring to is specifically to the implementation specifications for the transactions that are developed, where that is done exactly like you would see an NPRM done.
The document is put out on display, people can access it, download it, read it, make comments to it, send those comments back to the SDO, back to X12, and the work groups that publish those guides, and we would respond to those comments.
So, we would hold an open forum. First, the work groups would go through all the comments and respond to them, and then hold an open forum to review those publicly and take additional comments, get agreement on the resolutions that have been proposed, and then republish the implementation specifications as a final form, reflective of all those changes.
I believe HL7 is also doing that for the HIPAA implementation specifications that they have, and I am looking for Maria. Are you nodding yes to that?
MS. WARD: I was actually -- I didn't hear what you said you were doing.
MR. BECHTEL: You couldn't hear me? That has never happened before.
MR. REYNOLDS: Why don't we have Maria comment on that when she comes forward, so we can hear her, and also for the time that we have got to get everything in today.
When you testify later, if you would testify on this? We are going to hear this all day. We are going to get a lot of information today. We are not going to take this panel and make a decision, then go to the next panel and make a decision.
DR. HUFF: I guess if everybody understood that there was no other comment period, but one of the concerns I have basically is that, although there is an open consensus process in the standards organizations, the ability of people to participate in that process is actually not equal.
For instance, in HL7 -- and I am wondering if there are similar situations that we should be concerned about with X12 -- HL7 would love to have a bunch of practicing physicians and nurses participate in the meetings.
The reality is, those people can't, because they can't take the schedule, they don't want to pay the dues for the organization.
So, what you actually end up with is, you end up with predominantly vendor ideas represented out of proportion.
So, part of the value of sort of the NPRM process is the fact that they do have the ability to sort of watch and, when something comes out of the end of the pipeline, they can read the document and then say, this is really bad for physicians or this is really bad for nurses.
Even though it is -- quote unquote -- an open consensus process, is there some way that we need to engage certain people who wouldn't have the same opportunity or ability to participate in the process?
MR. BECHTEL: Again, I would say that the reason that we are asking for the notice in the Federal Register when a public comment period is being held, is exactly for that reason, to get to who would normally comment during the NPRM cycle to comment during the SDO cycle.
I will also tell you that, in the 005010 guides, the number of public responses or comments we received were really quite astounding. Well over 2,000 comments were received just on the claim transaction for 005010.
You know, they have gone through an enormous process of reviewing that document and taking public comment.
The majority of those 2,000 were not just the normal people. They were other entities that were paying attention to this.
I think it will get bigger if we have a Federal Register announcement as well, but we think this is reflective of what the industry is now doing with HIPAA. They are paying closer attention to it, and if we could get the announcements in the Federal Register, I think it would help.
MR. REYNOLDS: We are going to take a break now. I know a lot of us still have -- it is going to be a long day of issues. So, we will continue to build on these, and also we may have other people step up as we come forward. Thank you, and we will be back at 10:20, please.
[Brief recess.]
MR. REYNOLDS: If any of you have changes to the letter, if you will please pass those forward to Michael, what we are going to do today is, we are scheduled to adjourn at 1:30. We will probably adjourn at 2:00.
The reason is that we will go ahead and work on the letter for that last 30 minutes with everybody's changes. We have also gotten some changes from the pharmacy group.
We will try to work this out, and then we are going to work on a process as to how we can get this letter through the full committee and resolved by December 19. So, that is our process out of yesterday. That will be a monumental event, as we hear these hearings about speeding things up.
You can't get much faster than hearing testimony yesterday, getting a letter approved by the full committee by the 19th and in to the Secretary. That is moving pretty fast, with industry approval, which is exactly what we heard yesterday.
Agenda Item: Updating HIPAA Standards: The SDO Perspective.
MR. REYNOLDS: With that, we welcome our next panel, and that is continuing the SDO perspective. We are going to have Maria Ward from HL7, Lynne Gilbertson from NCPDP, Alix Goss from X12, and Frank Kyle from ADA. So, let's go in that order. Maria, welcome, and here we go.
MS. WARD: Lynne and Alix and I had talked previously about the order and, if it would be all right with everyone, I think we would like to sort of go this way, with Lynne first.
She is going to be provide some background and history, some of the initiatives that all three of these SDOs have been involved in. By doing that, she allows us to not have to go back through a lot of that. So, if that is okay?
MR. REYNOLDS: Sure. Lynne reset our schedule all day yesterday. We would be more than happy to have her decide that she is going first today again. Lynn, you may proceed.
Agenda Item: The SDO Perspective.
MS. GILBERTSON: Thank you, Harry. Lynne Gilbertson from the National Council for Prescription Drug Programs. This is the NCPDP testimony to NCVHS on updating HIPAA standards.
To give you a little background of the work that has gone on for quite a few years related to updating HIPAA standards, in 2002, the National Council for Prescription Drug Program members began working on a draft white paper discussing steps in naming a new or updated version to the HIPAA transactions due to the new versions of NCPDP standards that were approved since HIPAA.
In 2003, WEDI formed a task group with participants from the industry and the SDOs to take this paper and recommend a predictable and timely process that included steps for industry consultation and input for recommending a process for new versions, and updates to named versions under HIPAA.
The white paper included background information about the regulatory process, how modifications to standards occurred in the SDOs.
Sample time lines were built to show the steps and the approximate length of time, to help the reader understand the steps embedded in the HIPAA process.
The time lines made it apparent that the regulatory process took much of the time with no apparent gained benefit.
Representatives from the three standards development organizations volunteered to begin focusing the document on improvements in both the SDO and the regulatory process.
DSMO and the office of HIPAA standards at that time met for a one day session, to review the SDO and the regulatory process, look for ways to improve the process by which changes to the standards are made, and to speed up the process.
The meeting also included education on the American National Standards Institute requirements that the SDOs must follow to retain their accreditation.
Discussions centered on whether the SDO balloting/voting process and the notice of proposed rule making or NPRM public comment period could occur simultaneously to build a predictable, timely process.
Representatives of ASC X12N and NCPDP each met with OHS via conference calls to discussion coordination of the federal regulatory process with the SDO's process for version updates to current HIPAA transactions.
It was noted that defining a predictable process might be difficult, given the length of time and the steps that must be done in the regulatory process steps.
In 2004, the SDO representatives began revising the white paper to include more focus on education about the SDO and the regulatory process, and less on the predictability of the process.
The SDO representatives requested OHS' assistance in understanding what the APA really required, versus what other procedures were embedded in the process.
The SDO representatives spent considerable time discussing a proposal to overlap the SDO ballot or approval process, or the public comment period process, and the HHS public comment period. The SDOs requested OHS give consideration to some kind of predictability in the federal process.
After much work was completed to try to determine solutions, and with the participants frustrated, with the largest chunk of the time line appearing to be the least able to change, the paper was retired, but the exploration continued.
In 2005, much work has been done, and was done, exploring the overlap avenue. The SDOs met with OHS to discuss the proposal.
Important points emerged of: number one, the important need of a predictable timely process steps through the APA;
Modifications requested during the HHS public comment period could affect the approved SDO implementation guide;
Number three, that modifications requested by agencies reviewing the NPRM under the APA could affect the approved SDO implementation guide.
The current time line. The estimated time line from the DSMO change request submitted to the implementation deadline could take from four years, minimum, to any number of years maximum.
The current process time line does not include the SDO development time, as the implementation guide that is requested at the time of the DSMO change request is an approved guide.
The four year to XX year time line includes the DSMO process, NCVHS, the NPRM writing, the comment period, the deliberation of comments, the final rule writing, and the implementation dates.
There have been, and continue to be, concerns about the current process, in addition to the duration, including timeliness and predictability.
The current process. The industry requests a published implementation guide be named in HIPAA. The implementation has been through the SDO-based review and approval process, including ANSI.
When the NPRM public comment period finally occurs, an assumption made by OESS has occurred, that the published guide will be opened and modified.
With elapsed time from the DSMO change request submission to the NPRM, the SDO has moved on to developing a newer version.
If the newer version is complete, the problem now becomes incorporating changes from the NPRM process to the originally named version, making changes to the newer version, and resolving inconsistencies. This is a maintenance nightmare.
The original guide has been through the open process. Now there is another round of comments, which may be years after the original comments were made as part of the ballot or approval process.
These changes may require another SDO ballot or approval process, and could cause a new version to be named. Now, should another public comment period occur, the loop begin?
Further, there is the ability via the regulatory process for agencies who review the NPRM writing to request changes which may or may not have been vetted through the industry process.
Improved implementation guides should not be reopened. Comments should be made at one time during the SDO open process, and evaluated at that time.
In 2005, the DSMO collectively, and the SDOs individually, have spent many hours discussing the maintenance and the modification processes.
An emergency process was designed. The office of e health standards and services will be including these topics in an NPRM, slated for some time in 2006.
OESS has determined that it is possible, but will not be able to make any commitment. For example, if they received a DSMO change in November, they could project the following October for an NPRM publication and, 13 months later, the final rule.
The current time line with the OESS proposed schedule is a step in the streamline direction, but the length of time still remains a couple of years from the request of a version named to the actual implementation.
It does not address items two and three above. It does not address the multiple comment periods. Further, the times cited are approximate.
If the actual months are established and adhered to, predictability could be met. An overlapping comment period time line, with the OES proposed schedule, combines the requirements of one and two above.
It should be noted that the time line would still take a minimum of three years. It does not address item three above. It is a step in the right direction, but still not timely.
The environment today. Since 1999, the pharmacy industry has requested modifications to the NCPDP telecommunication standard, which has resulted in the creation of versions from 5.1 to C.2.
Change is the nature of the industry and, therefore, the standards. The industry has been tasked with considerable challenges due to the requirements of the MMA.
We have been forced to use text fields and interpretive guidance, otherwise known as cluges to those techies out there, for the implementations of medicare part D, because moving to a new version under HIPAA was not possible, given the time frames.
The process for change under HIPAA was broken before it ever began. The possible emergency to be discussed in an NPRM this year may offer a solution to a succinct problem with a succinct correction.
The reality is that the proposal will still take too long to go through the processes. There was very little time to do all the analysis required form the MMA, and in this I am specifically referring to medicare part D.
The industry is still discovering situations that they need to resolve. We would have had to request multiple emergency changes over this year, and the process would have tripped over itself with all the administrative steps.
In cases like this, the industry needs to work with the SDO in as many iterations as necessary to support the changes and implement based on the work.
The industry is being forced to support these cluges. They have to code to them, then later re-code to the real solution, when they would much prefer to code the real solution the first time.
We are still waiting on the NPRM for the billing of supplies and services, which are now more important under the medicare modernization act.
Now we are forced, with regulatory processes i the e prescribing environment. It is a reasonable expectation that this business practice will require changes to HIPAA named standards.
Waiting four or more years for a change to be in place is not acceptable. The industry must also be able to support two versions at a time, to ease migration and to respect that not all will need the changes in the latest version.
Some of the perceptions, true or false. The SDOs publish updated versions from as often as multiple times a year to every two years. It is not a long process.
The SDO process is important, because it does vette the technical and business perspectives. The federal regulatory process takes the largest chunk of time in the time line process.
How do you weigh the ability to update standards with the industry's time frame to move? Business practice is often to support the current version for some time, while moving to the new version. Then the current version is sunset as you move to the next version.
NCPDP, in its guidance to all its standards, states that any versions approved have a 180 day implementation time frame.
Prior to HIPAA, the industry moved as business needs required, and the pharmacy electronic claims submission rate was at approximately 95, using the telecom standard.
What are HIPAA and the regulatory processes attempting to solve. Is it a large stick, the mandating of a standard and a version when an entity apparently does not choose to move to the standard or version. Those who see benefit or have a need do move.
Forcing everyone on the same version of a standard, introducing regulatory processes that attempt to notify all of something happening and force new checks. What are we trying to solve.
Why would la new standard be requested under HIPAA, knowing what we do now? Perhaps the following represent basic tenets of what we are trying to accomplish.
Outreach should occur to as many as possible via multiple methods. The industry should be engaged in the standards development process in various ways as early as possible. Standards implementation should be predictable and timely.
A possible solution for HIPAA and e prescribing. The proposed steps below try to meet the basic tenets above. The steps would be the same whether it is a new version or a new standard.
The steps would include: industry -- this is extremely important to me, industry. The SDO is the mechanism, but it is the industry that has to request it.
Industry, via the SDO, approves that they wish to support a new version or a standard. They provide the benefits, the modifications made, the ballot or approval information, the public comment process -- whichever term they use -- and a recommended implementation time frame.
WEDI completes an industry survey based on this information. Notifications of the ballot or public comment period, or whatever you call it through the SDO, take place via HHS, the SDO, industry list-servs, and everything else that we have at our hands right now.
The SDO implements their ballot or approval process. Comments are vetted through this process. The final implementation guide is prepared.
The industry/SDO report to NCVHS of the industry requests, the time frame, the WEDI survey results. This is at an established time each year.
NCVHS sends recommendations to HHS within an established time frame each year.HHS notifies the public of updates and implementation time frame. The notification occurs at an established time each year.
There may not be an industry request each year, but the predictable time line would be established, so that if there is anything to bring forward, the schedule is known by the industry.
This solution offers some modifications. The DSMO process, the NPRM and the final rule process would no longer occur.
Each, in their own way, was intended to alert the industry of change and encourage involvement. With proper established notifications, the goals are still met of steps one, two and three early in the process, where input and involvement should occur.
HIPAA has taught us a lot. It is now time to apply those lessons learned, and admit that we are not supporting the industry need for change.
It is not timely and predictable, and the process is not streamlined. It is now time to adopt a proposed solution, start working through the details and implement. Thank you very much.
MR. REYNOLDS: Okay, process check. Do each of you now want to go through your own presentations? Okay. So, do you recommend another order? The order in which you are sitting. Okay.
Agenda Item: The SDO Perspective.
MR. GOSS: My name is Alix Goss. I am the director of health care standards for Washington Publishing Company, where my responsibilities include ASC X12 standards development work, and health care consulting.
Within X12, I am the chair of the insurance subcommittee and, on their behalf, I am a member of the designated standards maintenance organization, national uniform billing committee, national uniform claim committee, and the health information technology standards panel.
Today, I am presenting the X12 views on the important topic of updating HIPAA standards. Please note that the X12's written testimony contains far more details and explanation than can be provided today.
In consideration of time constraints, my testimony will only address the key lessons learned, and recommendations.
Experience to date and lessons learned. Standards development work is driven by industry needs. It is an iterative process resulting in improved standards being produced that meet businesses' evolving needs.
With HIPAA, standards and implementation guide specification activities have become more time consuming, and much more work has to be completed to get the implementation guides adopted by the federal process.
Specifically, the federal rule making steps dictated by the administrative procedures act, of APA, and various executive orders, such as 12-866, which X12N supports by preparing additional materials to be used by the federal government in their rule making processes, reviewing and commenting on notice of proposed rule making, and finally, supporting the federal government in responding to technical comments received in response to NPRM comments from others.
X12's volunteer staff does all of this, even though the NPRM comment period if an additional comment period to the public comment period already managed by X12.
As a part of X12, the insurance subcommittee, or X12N, process for implementation guide specification development is a well documented and vetted process that includes a public comment period freely open to anyone who wishes to comment.
With the adoption of HIPAA, much more work has to be completed to get the standards adopted by the federal process.
To date, the only real life example of making modifications to the HIPAA standards is the process to produce the addenda, affectionately referred to as the fast track process.
The fast track process took two years to complete, February 2001 to February 2003. During this process, there were times when there was a difficult dynamic in synching up government direction and industry consensus achieved in X12, and the public comment, review and resolution process.
Through extensive collaboration, and X12's focus on the big picture needs of the industry, the addenda specifications were finalized.
The addenda process came into play in order to have a rapid fix to implementation problems, recognizing the original 004010 mandate.
A so-called rapid fix or fast track process taking two years is indicating of how long a theoretical normal process will take.
Since the first HIPAA standards were adopted, X12 has processed thousands of requests for changes. The reason for the volume of changes is the amount of time between adopted versions, changing business environment, and more industry focus on health care standards.
Throughout the initial HIPAA adoption and normal development cycles, X12N has been actively engaged in identifying ways to shorten the length of time that it takes to adopt modifications to the HIPAA standards.
The importance of a predictable cycle is that it provides the industry with the information necessary to effectively plan, budget and allocate resources required to implement changes to the HIPAA standards.
To fulfill the administrative simplification provisions, Health and Human Services set forth 10 principles which must be met for a standard to be adopted.
The 10 principles support the regulatory goals of cost effectiveness and avoidance of burden, predictability, flexibility, and encouragement of innovation.
From our extensive analysis and discussions within X12, with our DSMO partners and WEDI, two repeating themes have emerged.
First, the standards development process is able to produce iterative work products on an established schedule.
Second, the federal rule making structure is not currently designed to provide a predictable schedule. The current federal rule making structure is counter to predictability and efficiency.
There are two items not accounted for in the current processing, developing a cost benefit analysis on new versions, and the time line to pilot transactions before adoption.
It should be noted that these remarks, and those in the written testimony, reflect activities leading to mandating a modified version, and do not address the industry's time to implement HIPAA standards.
I would like to now discuss our recommendations. Backward compatibility, as defined in the e prescribing final rule, states backward compatible means that the newer version would retain, at a minimum, the full functionality of the version previously adopted in regulation, and would permit the successful completion of the applicable transaction with entities that continue to use the previous version.
First, to ensure full understanding of the final rule preamble, we recommend NCVHS request the office of general counsel to provide documentation explaining the legal basis, precedent and justification for the e prescribing final rule comment that might permit waiving of the notice and comment steps in backward compatible situations.
In particular, this request is focused on understanding the basis for the final rule preamble text of, when determining whether to waive notice and comment, and whether to incorporate, by reference, multiple existing versions, we would consider the significance of any corrections or revisions to the standards, as well as whether the new version is backward compatible with previously adopted versions.
We are trying to understand why, and on what basis, does the government believe that a backward compatible standard can be adopted without formal rule making.
Second, based on the information we have today, we do not recommend pursuing the concept of backward compatibility for HIPAA transactions.
The backward compatibility concept, as currently defined, would prevent any functionality from being removed from specifications, even when the industry must have functionality removed or changed.
For instance, 005010 implementation guide functionality modifies provider information to meet the national provider identifier needs, and it not backward compatible with 004010-A-1.
Implementation specification development evolves faster than HIPAA mandates occur. The development process occurs because industry needs are changing.
Voluntary adoption of new specifications does not achieve standardization, because it undermines the goals of administration simplification to achieve consistency and avoidance of burden.
For instance, permitting the industry to have a new and old version of standard in play for an undefined and extended period of time will result in coordination of benefit complexities.
This will occur because different trading partners will submit different data sets of information, and trading partners downstream of an initial claims submission may or may not receive all the information necessary to process a COB claim.
Functionality in a new version of a specification cannot be guaranteed to be the same as previous specification versions due to industry needs or change requests received by the SDO or DSMO change request processes.
The DSMO process provides the industry with a mandated vehicle for requesting changes. Backward compatibility requirements negate the mandate of the DSMO process to effectively maintain the HIPAA standards.
The concept of backward compatibility is counter to the iterative standards development process. A fundamental characteristic of standards work is to evolve the standard based on industry needs.
We learn from the industry's prior implementation efforts, resulting in modified guidance and/or function within a specification.
The concept of backward compatibility is a great one, but it is not always realistic. Rather than backward compatibility, are we trying to address the migration path for moving the industry forward to newer specifications.
We believe this is the crux of the issue that needs to be resolved, and the remaining recommendations will focus on this.
Much to your surprise, we recommend eliminating the federal notice of proposed rule making process for adopting modifications to existing HIPAA standards.
Reasons for this are as follows: being able to support modified standards every five years is insufficient for meeting the needs of the evolving health care world. We need to support industry needs in a more agile method than currently exists.
X12 is working hard to have new implementation specifications generated in a routine cycle. This results in new specifications being available in a considerably shorter time frame for adoption, if we do not have a federal notice and comment period required.
By having the federal comment period in play, portions of the industry are not participating in the standards development comment process.
This means the industry input is not being effectively managed, resulting in the potential for additional delays to standard adoption.
The federal comment period could result in another version of a specification being generated and cycled through the SDO process, thus further delaying the adoption.
We propose that, when the SDO issues their public comment period announcement, the government shall publish corresponding notices in the Federal Register, and through its HIPAA and other applicable list-servs.
Part of the notice shall indicate that no NPRM comment period will occur for the SDO's implementation specifications, and the industry shall submit their comments in the SDO public comment period.
If the government believes that there will also be policy items requiring public comment, it shall indicate that these are not included in the SDO materials, but will be included in an NPRM specifically dedicated to policy issues. We believe any policy decisions necessitate the proposed rule making public comment process.
With recommending the elimination of notice and comment rule making, we are also recommending a final rule with comment be generated as part of the adoption process, to achieve the same force of standardization.
The industry appears to need the security of a final rule before they are willing to implement a modified HIPAA standard.
These recommendations approach HIPAA standards adoption like the current process for routine code set updates that are permitted without final rule making.
We would like to see the HIPAA law modified to permit modifications to an adopted standard to occur without notice and comment rule making. If this is not feasible, then we request education on why.
We also recommend adopting modifications to HIPAA standards that define specific migration approach and time table, so that only one version is supported in the industry after the migration time is completed.
The approach to conversion and overlap between versions is extremely critical to implementation success.The only time two versions would be supported is during the migration time frame.
Maintaining one version addresses the administrative simplification principles of eliminating undue burden and promoting cost effectiveness.
Allowing an old version to be maintained indefinitely permits trading partners to delay migration, which negatively impacts data flow, such as in COB exchanges.
In January 2004, WEDI held hearings to obtain industry feedback on the implementation efforts of transaction and code set regulations.
It was very clear from the testimony that future transitions need to have a staggered approach to roll out by covered entity. There was an overwhelming agreement on the flow of adoption by covered entities.
Payers transition first to enable stable systems, complete companion guides and effective communication with their trading partners.
Then clearinghouses transition either in tandem with payers or immediately thereafter. Providers would be the last to implement, thus minimizing the burden on the most populous types of covered entities.
Sequencing of transactions by function should also be staggered in the future. Claims should not have been first, some say.
Many reference the eligibility transaction as being a good place to start. The volume of future changes need to be assessed and controlled to manage the impact to the industry.
Finally, we recommend continuing the federal notice of proposed rule making process for adopting new HIPAA standards.
This concludes my remarks on behalf of X12. Again, thank you for this opportunity to testify, and I look forward to your questions.
Agenda Item: The SDO Perspective.
MS. WARD: Mr. Chairman and members of the subcommittee, Health Level 7 thanks you for the opportunity to provide remarks today on the subject of the standards development organization process, and how it works in the regulatory environment.
My name is Maria Ward and I am a co-chair of the HL7 attachment special interest group, as well as HL7's primary representative to the DSMO, HL7 liaison to X12, and HL7's representative on the national uniform claim committee.
Founded in 1987, HL7 is a non-profit, ANSI accredited standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services.
HL7's more than 2,000 members represent approximately 500 corporate members, including 90 percent of the largest information system vendors serving health care.
My comments today will be in the context of the work HL7 has done as part of the DSMO for the past several years, as it relates to the topic of the SDOs and regulatory processes.
My comments are limited to the SMO experience, as I am only referring to the work we do in HL7 for claims attachments, which is a proposed HIPAA standard, as opposed to work products from other HL7 committees that are not subject to the regulatory process discussed today.
HL7 has worked very closely with NCPDP and X12 to address issues within the SDO and regulatory process, as part of the DSMO. We will keep our remarks brief, as many of the important points have already been addressed by NCPDP and/or X12 in their testimony today.
The SDOs took on the challenge of identifying and attempting to resolve problems related to the regulatory process under a variety of different initiatives, including a white paper on versioning, a subsequent effort with all DSMO organizations to determine an emergency change process for the SDOs to execute if needed and, finally, a process we call dove tailing, whereby the SDOs explored alternatives to their current specification, creation and ballot process.
It should be noted that, while each SDO may have had variations on the precise impact to their process, we all came to the same general conclusion: The SDO process isn't the real issue.
The difficulty we identified is with the regulatory process. For example, while waiting for imminent release of the claims attachment NPRM, the cited specifications could have, and should have, gone through updates and revisions. This was put on hold, necessarily, because there was no notion of when the NPRM would begin.
Every discussion, some of which included detailed process flows and time lines, resulted in this being a significant problem.
With a regulatory process that is not predictable, although it may seem subtle, we are talking about when it begins or when it ends.
To begin an NPRM process, we know that happened in 1998 for claims attachments, but we didn't actually see it until 2005.
So, to say we can begin an NPRM process at one point isn't particularly meaningful to us, as SDOs. We just wanted to point that out.
It is potentially very lengthy. The hands of the SDOs are tied. Regardless of how creative we have tried to be throughout these deliberations, we can't control the timing when new or updated standards are able to be used.
Because of this, our ability to be responsive to industry needs is compromised, again, in the context of standards adopted for use through the regulatory process.
We would like to provide you with a few examples of where the SDOs attempted to think creatively and find alternatives to the existing process.
In each case, the ultimate conclusion was that, from the perspective of OESS, these would likely not be workable alternatives.
In most, if not all, cases, the administrative procedures act played a key role in the OESS response to us. It is worth noting that OESS representatives to the DSMO worked very hard to discuss these alternatives with us, and we all sought to strike a balance between SDO and HHS obligations.
Unfortunately, we were unsuccessful in this endeavor. For example, we asked, could HHS forego the NPRM and comment period, and announce to all of their list server participants, when an SDO new version if available for SDO public comment or ballot.
Could this announcement and advisement to participate and comment during the SDO period suffice? Could HHS issue an NPRM that essentially says, take it or leave it, this is what it is going to be, versus opening it up for comment that could result in revisions to the documents. Could HHS issue a final with comment and forego the NPRM?
In all cases, it was felt that the issuance of the NPRM was a critical step in this process and could not be avoided.
NL7 understands the importance of the NPRM process and appreciates the need for the public to have not only notice, but opportunity to comment on proposed standards.
Given that, and knowing the SDO process isn't the problem when talking about moving new standards into the industry faster.
It seems as though, despite several years of attempting to resolve this, the basic problem still exists. How can SDO be more responsive to industry need while working within the constraints of the regulatory process?
We don't believe we can, but we would like to offer several alternatives to the current approach. Indeed, the NCVHS comment letter dated November 22, 2005, in response to the NPRM for claims attachment even echoes the need for an improved process.
We understand that some, if not all, of these recommendations have, in the past, been met with the response that they are not achievable in the current regulatory environment.
HL7 asks whether they can be considered again, doing whatever needs to be done from the federal perspective to allow them to work.
Recommendations. Number one, for new versions of existing standards already adopted under HIPAA -- for example, a new version of an X12 implementation guide or an HL7 additional information specification once they are named as standards -- do not require an NPRM process.
Allow an alternative process to suffice, where the industry would not have to wait for the NPRM process to finish, then an additional 12 to 24 months to implement the standard.
One recommendation for this alternative process would be, a, industry, along with the SDO, determines the need for a new version.
Appropriate documentation is prepared to demonstrate the need for a new version, proposed changes, and announcement information for upcoming ballot.
B, the SDO announces the upcoming ballot. Other industry organizations, as well as HHS, should also announce this, in order to gain the most participation in the ballot process.
C, the SDO prepares and approves, through their ballot process -- which is an open process whereby comments and questions on the specifications are submitted, along with a negative or affirmative vote -- a new version of an existing HIPAA standard. This includes reconciliation of all negative comments to the ballot.
D, either in parallel or shortly after step A, as was done with the request to advance a new version of the X12 835, WEDI conducts an industry survey related to the ROI associated with the new version.
It is noted here that the SDO may also have input to some of the ROI information and be able to work with WEDI on that.
E, the final specification is prepared, reflective of any changes approved through the SDO process.
F, the DSMO reviews and approves the new version. This step includes not only the SDO documentation, but also the WEDI ROI information.
G, as part of the annual DSMO report to the NCVHS, the approval of a new version of the standard and the ROI information are reported.
H, at a predetermined time each year, notification of the new version, ROI report and implementation time lines are announced. There may be some years when a new version is no necessary.
The decision for such a process has been echoed clearly among a number of national industry groups as they currently review and respond to the NPRM for claims attachments.
Whether it has been the discussions in HL7, X12, NUCC, NUBC or WEDI, each and every time there was a clear consensus that the current NPRM process does not work, and organizations are commenting not to require it for either modifications to existing attachments, or the introduction of new attachments.
You will see comments that, once the DSMO process has completed, there should be no continuance on to the NPRM process.
Appropriate steps should be in place for notification, and ample time allowed for implementation, but in all of these discussions it was clear that the industry stakeholders wanted to stop the process before the NPRM step.
Other comments will say that both the DSMO and the NCVHS steps should be completed, but again, no continuance on to the NPRM process.
Some individuals even went as far as to suggest a comment saying that the HL7 specifications were not standards simply so they would not be subject to the regulatory process.
For new standards introduced under HIPAA, either follow the same process as proposed in recommendation number one above, or create a more detailed process that ensures public input and common opportunity but, again, allow the SDOs and industry to work through the details of this process and do not require the NPRM course of action.
In either case, have the SDOs, along with other industry stakeholder groups, determine what is acceptable for the industry in terms of, a, the frequency of roll out of new versions.
This discussion should include a dialogue about how long it takes SDOs, vendors and clearinghouses, as well as health plans and providers, to be able to support a new version.
HIPAA requires that new versions not be introduced more frequently than once every 12 months, but it may be industry consensus that it should be every 18 or 24 months. This needs to be addressed.
B, whether there should be a period of supporting both the existing and new version for covered entities. If so, how long should it be before the old version is sunsetted.
C, what is the process whereby industry provides comments to the SDOs regarding new standards, assuming there is no NPRM. Is it during the SDO ballot cycle or public comment period? Is it an additional step?
D, how are the processes communicated to assure that all affected covered entities have the opportunity to provide input.
Number four, assure that the process allows for predictability in advancing to new versions or new standards. Whether this is an industry created process, as suggested above, or a process that the government can commit to, it needs to be predictable and timely.
Several examples of where this works well are with updates to vocabularies, like CPT, on an annual basis, which everyone is aware of, or updates to the medicare fee schedule. Both are predictable, so that implementers can plan and prepare for it.
Most important, determine what needs to happen at the federal or congressional level, to allow us to move in this direction and begin to support a process that is more responsive to industry needs.
Finally, HL7 understands that OESS is interested in our perspective as it relates to backward compatibility of new versions of standards.
It is HL7's position that subsequent versions of the standard should not remove any functionality supported by previous versions.
Further, components may be added to messages, but the content and supporting vocabularies defined by prior versions should be maintained.
In general, changes can include the addition of new components, renaming of components including XML, element, attribute names and CDA schema, a deprecation of components defined in a prior release, a change in cardinality of a component, or a change in a vocabulary domain of a component.
In closing, HL7 is pleased to have been involved in these discussions with OESS and the other SDOs over the past several years.
Through our efforts to address the issues, we have learned a lot. Perhaps most important, we know that the core of the problem can't be resolved by the SDOs, regardless of how creative and flexible we try to be.
HL7 believes that action needs to be taken at the federal or congressional level, for changes to occur that will allow us to be responsive in support of industry needs in a predictable and timely manner.
As cited above, and also by our fellow SDOs today, a number of possible ways to begin thinking about this have already been identified.
We look forward to further discussing our recommendations, as well as NCPDP's and X12's, with the NCVHS and OESS, so we can move forward on this important issue. I would like to thank you for the opportunity and I am happy to answer questions.
MR. REYNOLDS: Thank you, Maria, and Frank, you have to be next.
Agenda Item: The SDO Perspective.
MR. KYLE: Thank you, on behalf of the American Dental Association, for the opportunity to testify this morning.
As you know, the American Dental Association, or ADA, is a member organization of approximately 152,000 dentist members, or roughly 72 percent of the dentists in the United States are members of the ADA.
That is a blessing, but it is also a problem, in that there is a wide variety of opinion and experience within that large population of dentists.
So, you will find a wide gamut of thought processes, particularly when it comes to electronic transactions and the whole basic subject area that we are talking about today.
I hate to start off with apologies and excuses, but I think I should explain something. I am a dentist. My official title is manager of legislative and regulatory policy for the ADA in the Washington D.C. office. Their headquarters, of course, as you know, is in Chicago.
You will notice that nowhere in that title does it say anything about electronic transactions or code sets or anything like that.
The true expertise for the American Dental Association lies in Chicago. Some of you, I think, know Bob Owens, who has testified before the NCVHS on previous occasions, Frank Fracorni(?), and so on.
I only learned of this opportunity to testify on Monday afternoon of this week, and it wasn't until yesterday afternoon that I was able to work with Frank Fracorni to develop our comments.
To be honest with you, they have not been fully vetted through our organization. I believe them to be accurate and complete, but I don't have written copies to provide for you today.
If the committee would like, we could provide a written copy at a later date, but I do need to have some further vetting through our organization. Again, it is a member organization and we need to make sure that we are speaking what the members would want us to say. So, I would be happy to do that, but it would be a few days before I can do that.
It is my understanding that the ADA was asked to discuss a little bit about its role as a standards development organization, a little bit about the scheduling of HIPAA standards, and something about versioning.
If there were other topics to be addressed, I am not aware of those, but that is what was given to me. So, having said that, I think you know that the ADA is a voting member of the ANSI X12 group.
Its participation extends back for over a decade. It is an ANSI accredited standards organization and it develops dental informatics standards through our standards committee on dental informatics or SCDI.
The SCDI is responsible for a number of standards that affect dentistry ranging from technical specifications for things like dental materials and equipment and supplies, composite resins, for instance, dental burrs, those sorts of things, development of interoperability standards for radiographs through Dicom, and dental informatics. An example of that would be the electronic health record and particularly the periodontal attachment standard for data that is currently being developed in accordance with a memorandum of understanding with HL7.
I guess the comment that should be made there is that that is of particular note. The ADA provides the content, if you will, for that electronic standard, with HL7 providing the technical solution to the attachment.
We also bring that particular standard up because we note that that is the type of attachment transaction that is identified as a possible HIPAA standard for claims attachments under this proposed rule that has just recently been let for public comment.
In the two years since the implementation of the final rule on transaction and code sets, the volume of electronic dental claims has grown to approximately 30 to 35 percent of all dental claims.
Now, I suspect that that is a significantly lower level than what you find in the rest of the industry, and again, I am not that familiar with the term, but I believe it is the 837D or the dental form of the transaction set that is the one most commonly used by dentists across the United States.
From the information that the ADA has, use of other HIPAA standard transactions is negligible. We believe that a factor in the lack of implementation in dentistry is the nature of dental practices.
Again, the vast majority of dentists in practice are in solo or small group practices, and they rely for their technical resources, on the practice management system vendors and clearinghouses, to be able to do these things. It is my understanding that that development is not perhaps as advanced as it is in the physician arena.
Another consideration is that the individual practitioner's decision in making electronic transactions is sort of a cost benefit evaluation.
One of the negatives, if you will, at least for some of our providers is that, by doing electronic transactions, they then become covered entities under the HIPAA rules and, for some, there is a negative connotation with having to comply with all the other HIPAA regulations for covered entities.
Now, the ADA is committed to promoting electronic commerce and HIPAA standards. We do have on our web site a cost benefit estimation tool that allows the individual dentists to model various scenarios that they can use for implementation of the HIPAA standards.
This tool has been adopted by other entities such as the National Dental EDI Council, with the goal of increasing the use of standardized transactions in dentistry.
In our opinion, the relatively modest penetration of electronic data claims alone, compared to figures for the institutions and physician practices strongly suggests that unscheduled and frequent -- perceived or otherwise -- changes to the existing HIPAA standards will not foster faster implementations of electronic transactions in dentistry. It is the old problem of the moving target.
A schedule for the introduction of the revised standards with a realistic implementation period would be seen as a very positive thing for dentistry.
Lastly, we wanted to make some comments about versioning, and this is my understanding of what versioning is so, if I am misspeaking here, please help me.
As I understand it, it refers to a situation where one version of a transaction type -- and the example given to me was the version 004050 of the 835 remittance advice -- is compatible with a different version of another transaction type and, again, the comparison example if 004010 of the 837D dental claim.
We believe that would be beneficial to our members that are engaged in the electronic transmission of business. This would allow the introduction, where there is a demonstrable business need, of a newer and expectedly more robust version of one transaction without requiring a submitter or receiver to change to the same new version for all transactions.
Such a focused change would seem to be less intrusive and less costly than a complete overall of the application software and the business processes.
I guess the phrase that comes to mind here is avoiding the appearance of planned obsolescence or change for change's sake.
Finally, I recognize that these are brief comments, and I hope that will not be objectionable to the committee. If you do have questions, I would be happy to answer them, or I would be happy to take those questions to our experts in Chicago. I thank the committee for the time.
MR. REYNOLDS: Thanks to all of you. I let everybody else ask questions last time. I am going to start this time, and then I will go around the table.
Agenda Item: Questions and Answers.
MR. REYNOLDS: As we have listened the entire morning, one of the things that strikes me, at least what I have seen, the development of the standards has many times been done by subject matter experts, companies and so on.
It would appear, with the added responsibility that the SDOs are asking for, that the make up of the people that would be part of some of these committees may need to change.
There may need to be more committees. For example, you take a standard, you have the EDI portions of it, you have the operations and business practices, you have the financing, especially when it is going back and forth from providers to payers, and you have the time frame and so on.
I have done some studies as I have been around the national committees, and if you ask CIOs or business leaders who is on any of these committees, they don't know.
That is not good or bad. They don't know, because they are not necessarily working at that level, or a lot of this is looked at as data and content, not necessarily business practices.
How do you see you changing, or do you think you have to change. The responsibility that you are asking for opens it to much more of a robust view, people looking at it closer, people questioning it closer, which a lot of times happens in other places, not necessarily in some of those.
So, that would be my first question. Then the second question that a couple of you hit on was, you mentioned a yearly visit to NCVHS.
In the one testimony, I think, Lynn, in yours, they talk about a process where we might send forward recommendations to the secretary.
Maria, in yours, it seemed to be saying that it would be a report to us, not necessarily anything we would do with it. I am only saying what I thought I heard, not what you said. I would like to open those two to the panel, and then I will proceed with the rest of the list.
MS. WARD: I will go first. The make up of any particular committee that works on these standards, I know exactly what you are saying because I have been involved in several of the different standards organizations committees as well.
One of the things we do in the attachments group within HL7, I think, is a little bit different. As we develop any specific new attachment type, it is not the members of the work group that actually develop it.
We acknowledge that we are not the domain experts for something like dental. That was actually a good example. We reach out to whomever it is that has the content and business expertise for -- we did it with ambulance, we did it with emergency department, we did it with rehab, and we continue to do it with home health and the other ones we are developing now.
We go through what we call an outreach process. Whenever we get the idea to begin developing a new attachment, when someone brings it to us, we submit requests to as many organizations at a national and state and local level as we can, to say we are going to do this and we need you to come to the table and participate.
So, each of our attachment types are developed in that way. They aren't developed by the actual folks who make up the attachment special interest group, with the exception of a few who will sort of monitor and facilitate and mentor people in that group.
So, each and every time there is a new attachment, there is a new group of people that is giving input into that.
So, we like to think, at least, that we are doing a pretty good job of reaching the right community. We try to make it a very diverse payer, provider, vendor association. Anybody and everybody is invited.
The reality is, very few of anybody and everybody actually shows up, even though they are invited, which I think is a fairly widely shared commentary of a lot of what we do.
The effort goes out there for announcement and notifications. I don't know what we can do better. I think what is suggested in some of our testimonies was, at the point where we are doing development or we are going through a ballot, that that be announced in a much more public way.
If HHS could take some of that on, I think that would hit an audience that isn't necessarily being hit by the SDOs themselves.
On your second question about the involvement of the NCVHS, I didn't intentionally exclude a report to the secretary. I realize I didn't say it either. It wasn't there, though.
When I was referring to the report to the NCVHS, i was referring to the annual DSMO report that comes to this committee.
I think the natural result of that is that some sort of letter does go to the secretary as a result of that annual report. That seems to be a very reasonable or outcome or next step from that.
MR. REYNOLDS: Did you include the NCVHS as part of the process or simply as an informational presentation.
MS. WARD: As part of the process.
MR. REYNOLDS: Again, I don't care what your answer is. I am not correcting your answer, I am just asking for clarification.
MS. WARD: Essentially, we were saying, the process works really well today, up to that point. What has to happen, what triggers the whole regulatory piece of it after that seems to be the crux of the issue for us.
MR. REYNOLDS: It is clear what everybody is saying about the NPRM. The earlier testifiers didn't mention what we would or wouldn't do. You guys have mentioned it briefly in a number of different ways. I am just trying to get a sense of -- again, not good or bad, just a sense of what it means. Thank you, Marie. Lynne, did you want to comment, since you had similar?
MS. GILBERTSON: Okay, question number one about the SDO change, I think there is no doubt that there will be change within each of the SDOs to embrace more of this process.
A, we have to get the devil in the details. Alice, Marie and I have worked through this for three or four years of project time lines, and I don't know, my anal retentive step by step by steps I sent them saying, let's try to figure out where there are gaps, where we can fix, we have been through this many times trying to figure out where could the SDO modify some of the process, where could the federal regulatory process modify all those different things.
I think we are definitely willing to change if the overall picture would change, the predictability, the time line and the not reopening documents.
NCPDP ballots whenever members bring forth changes, which is a process that is public now which is four times a year.
We might not continue four a year. We might do one, we might do two. We might have more impact based on more public comment, perhaps.
Again, when the standards are open for ballot, the entire membership is notified, the entire public is notified that is on our mailing list of those notifications, and we go through the ANSI process, which has its own notification processes. There might be some modifications that will occur to that.
As far as NCVHS, I viewed, based on all the iterations we have gone through over the years, that NCVHS was the conduit to HHS.
So, industry requests would come through at a timely predictable manner to the committee for recommendation to HHS, so that those two processes would continue.
So, I viewed at least the report, so that you could see that we had prepared, here are the recommended changes, here are the industry impact based on WEDI surveys, here is benefit -- you know, whatever we can bring forward to make it a complete package, that we would then bring it o the committee, so that you would have the information to pose a recommendation to HHS.
MS. GOSS: I would like to comment on your first question about the SDO make up of our membership. I would certainly hope that, if we were to eliminate a federal rule making process for proposing changes, that we would have more participation at the SDO level, specifically at X12.
This could happen in two different stages. We would love to see you at the table discussing the business needs that are brought forth from other people as well as bringing them forth themselves, that evolve into the technical solutions provided in the implementation guides.
The industry could not only participate there -- we would love to have them at the table -- but also, they have the same opportunity to provide the comments during X12s public comment period that they do during the NPRM comment period.
If they start to pay attention at an earlier stage, and bring their voice to the table, then their business needs are going to be met, and there is going to be a compromise in the technical solution that allows everybody to exchange the information that needs to be done.
We want people to come to the table and, right now, I don't think they are because they see that NPRM stage as their place they can pay attention.
They will have a more effective voice, a more current voice, and really be able to drive things better if they come all the way back to the X12 stage.
MR. KYLE: I will have to check on the exact member of the SCDI and so on, but my basic belief is that we do have considerable input from a wide variety of folks in the development of our standards, whichever standard you are talking about, industry or practitioners, et cetera.
DR. STEINDEL: I would like to first make a small comment and then a question, but not to the panel, but to Stanley.
My comment is, there are numerous federal agencies that are also impacted by the time frame of the introduction of HIPAA standards.
We have very similar problems to what are voiced by the people, the panelists, from both of these panels. In that regard, what struck me were these repeated comments from many of the panel members, that you have had continuing discussions with the office of now E health standards and services, concerning ways to improve this process.
In particular, Maria, in her report, enumerated three very specific comment areas. The first one, could HHS forego the NPRM, et cetera, and the second, could HHS issue an NPRM that essentially says take it or leave it.
The third one was, could HHS issue a final comment and forego the NPRM. The comments that were made by the panel was that, in all cases that you talked to the office you were told no.
Yet, those of us who follow various and multiple federal regulations concerning standards that have to follow the administrative procedures act, from multiple departments, have seen instances when all of these were done.
I would like to know the reasons, from the office of E health standards and services, why they said no, and Stanley doesn't have to answer that right now, but I think that is something that NCVHS should receive information on.
I do believe -- and it might have been Lynne, but I am not 100 percent certain -- one person on this panel actually suggested that as a course. That is my question and comment.
MR. REYNOLDS: Stanley, if you push the button, you are in.
DR. NACHIMSON: Thank you. My attorney is sitting in the corner and, if I go astray, please set me straight. I think we have raised a number of these possibilities working with our office of general counsel, to see if there is a way that we could use the regulatory process differently than it currently exists.
We certainly share the frustration with the length and unpredictability of the regulatory process. i think there is sort of a conflict between the mandating of standards and the wish to make them more flexible. I think that is where we get into some of these problems.
It is a confluence of the administrative procedures act and the HIPAA requirements, that sort of mandate our use of the notice and comment rule making process.
As far as we can see, unless we can figure out a way of somehow giving the SDOs some more authority, we do have to go through the NPRM and get the public comment.
The issue of the sort of take it or leave it NPRM was something that we talked about, but people were a little concerned about the take it or leave it meant, if we proposed a new standard, that the industry at least thought was good, and the comments came back no, that means that standard was essentially dead, we are stuck with the same standard, the old standard, for probably an inordinate amount of time, because we then have to go through the whole proposed rule making process all over again. So, instead of a four-year delay, it probably gets to an eight-year delay, which is probably even worse.
I can say that we are continuing discussions with the office of general counsel to see if there is a way of streamlining this.
We certainly heard these concerns expressed and we are continuing to pursue them. Whether we will have any success, I certainly can't say.
MR. BLAIR: Stanley, do I understand that the requirement for the administrative procedures act is invoked when the word mandated is inserted? Is that the thing that triggers that?
MR. NACHIMSON: Maybe that is something that I ought to turn over to the attorney, because you are talking about basically an interpretation of both the administrative procedures act and the HIPAA legislation. Is it all right if Mark --
MR. REYNOLDS: Yes, come up to a microphone if you would, please.
MR. MANTOOTH: I wasn't here earlier this morning to hear Maria's presentation. So, it is difficult for me to comment on it.
I also want to clarify that, since I am counsel for the department and not for this FACA committee, I can't provide legal advice to the committee itself.
With that said, with regard to the administrative procedures act, the statute provides that, if a federal regulation that is requiring or mandating certain obligations on the private sector, or providing certain rights to the private sector, that it has to be provided -- those provisions have to be provided through a notice of comment rule making process, giving the public an opportunity to comment on those rights or obligations that are going to be imposed on it.
So, in addition to the administrative procedures act, there are also other issues to consider, one of which is, to what extent can the department delegate what are essentially federal obligations, or obligations of a federal nature onto a private entity, such as an SDO, whether or not there is an improper delegation of federal authority.
So, in addition, the APA considerations all seem to be constitutional considerations given. In this discussion as well, there should be some considerations as well to what we are talking about with regard to standards.
In some cases, and in some of the cases that I think may have been discussed earlier this morning, referred, in addition to prescriptive standards, such as following transaction standards, to performance standards, which are more similar to what, let's say, the EPA establishes for levels of pollutants, or an element for certification under JAHCO.
To extent does a department rely upon that private sector standard setting body and its standard, in order to make a determination of whether or not private entities are complying with federal requirements.
In other words, if JAHCO establishes certain performance standards for hospitals, and those hospitals seek to meet those standards, there may be a certification by JAHCO, but a federal department could not simply delegate the authority to JAHCO, and provide for that entity to receive certain federal benefits.
There has to be retained a certain element of ultimate federal authority in looking at that certification. So, there still needs to be -- it cannot be a full delegation of federal authority.
So, when we are talking about standards, we have to consider types of standards, and what actually is taking place with regard to the federal requirements, as well as what Stanley mentioned earlier is the concept of enforcement.
If it is a performance standard, it is simply a certification, let's say, but in this case, for transaction standards, we are seeking to require private entities to comply with these standards on an ongoing basis, and have the department retain enforcement authority to make sure those private entities comply with those ongoing standards.
DR. REYNOLDS: Simon has a follow up to your comments and then Jeff may have a different question.
MR. COHN: First of all, I want to thank you very much for joining us. I realize you are certainly not our attorney. On the other hand, as a FACA committee to the U.S. Department of Health and Human Services, I am hoping that we can at least ask you some questions and get your involvement.
I certainly understand what you are saying, and I think we are all in agreement that these are not performance standards, as you described, but transaction standards.
I was curious, in your framing of your comments -- perhaps I am slicing unnecessarily -- but certainly there was an issue relating to new standards or new responsibilities and requirements to the private sector. I mean, I really understand what you are saying and agree with it.
I am actually wondering if the same issue applies to versioning changes to those administrative standards. Do you have a sense, is it equal in the eyes of the law, or is this something that is more open to interpretation.
MR. MANTOOTH: I think it depends on, if we are looking specifically in the context of transaction standards with regard to HIPAA.
The reason I qualify this, as you know, two of the three sets of standards that were adopting in the e prescribing standards rule were also HIPAA standards, and that has statutory authority that is different than HIPAa, which also raises some additional issues.
With regard to versioning, one of the other considerations in the context of both HIPAA and the e prescribing standards final rule is that the standards themselves, the implementation guides or implementation specifications were adopted by incorporation by reference.
The legal effect of that is that the implementation guides, these large guides several hundred pages long, in fact, are incorporated by incorporation by reference, meaning that the guides themselves are part of the regulatory text.
So, if there is any change to those guides that is made, and that change is being imposed on the private sector, then you have to go through a notice and comment rule making.
There have been a number of cases, including Supreme Court cases, where technical changes were sought, and the APA process still had to be followed, even to make those technical changes. So, with regard to versioning, you still have to follow the NPRM process.
MR. BLAIR: I think you probably have a receptive audience with the idea of doing what we can to streamline the adoption of health care information technology standards.
So, I think that some of the questions that are coming on here are sort of like, okay, if we wind up accepting your suggestions, then how do we do other things that might have been, in one way or another, associated with that.
I am wondering if, in the discussions that all of you had, as you began to come up with this recommendation, that the NPRM process be eliminated, what effect that might have on some of the other things, such as the pilot testing of the e prescribing standards, which is being funded by the federal government, or other examinations or research in terms of the impact, the financial impact.
I think you indicated WEDI could wind up doing some surveys, but let me go back and just focus on the pilot tests. Were there any discussions or thoughts?
At least in my mind, I tend to look at the pilot test as an acceleration vehicle. The fact that the federal government put in place a date to do the testing, to try to resolve some issues as quickly as possible, and then to follow that with adopting the e prescribing standards nationally, at least in my view, I was looking upon that as a way to try to accelerate things. Of course, that came to us from congress. Anyway, what thoughts do you have on that, if you do have some?
MR. REYNOLDS: That is to the panel. Stanley, you guys can stand down for a minute if you want. We kind of dragged you guys into this. I think we are asking the panel right now. You don't have to feel that, every time there is a question, you are in the middle.
MS. GILBERTSON: I guess, could you pose the question again? I understood what you said, Jeff, but I am not quite sure what the question was.
MR. BLAIR: The question is an open ended question. Did any of you consider some of the other things that the federal government does to try to accelerate the development and adoption of standards, that might be affected by not having the NPRM process.
I tend to think that the federal funding for e prescribing testing that is going to begin in a few weeks, at least I tend to think of that as associated with NPRM.
I sort of figure like, if we don't have the NPRM process, then was there any discussion in terms of other associated government initiatives, like testing?
MR. REYNOLDS: Maybe a more general question that might go along with that is, if it becomes a private sector process, is the government going to be willing to step up to fund the preliminary stages, which is exactly what the piloting and everything is for e prescribing, without being part of the process.
MS. GOSS: Right now we are not having pilots funded by the government for transactions and code sets. We had it when we had medicare, they did some pilot testing for claims attachments, and I will definitely defer to Maria on that one.
For the scope of testing the claim and eligibility and pre-authorization and remittance advice, there has been no funding to take care of the pilot testing.
I think if we got out of the federal promulgation business, and got back into the private industry driving that, that people would probably be more likely to want to step up and do pilot testing than they are now. They are waiting for the hammer to fall right now.
MS. WARD: I would echo exactly what Alix just said. I mean, from our perspective, from the X12 perspective and our perspective in HL7, there is no correlation between anything else happening at a federal level and this NPRM that we have.
The exception is that medicare, as a payer, did fund a pretty small amount of money went to funding a very small scoped medicare pilot for claims attachments, that started before the NPRM came out.
Now, I don't know if we are lucky from the HL7 side or we have just been working so hard we are starting to see the fruit of our labor, but there are more and more pilots that have no funding from anyone.
What they have are participants who actually see a value in an ROI in doing this. On a positive note, the pilot, the very small pilot that took place at Empire Medicare Services, at least one of the providers, Montefiore, wants to go into production, because just through their experience in the pilot, they already see the money they are going to save in doing this.
Our testimony today was based really on our DSMO deliberations over the past couple of years, at least HL7's was.
MR. REYNOLDS: I know we are a little over time, but this is a key discussion, so I am going to let it continue a little bit.
MS. BURKE-BEBEE: Dr. Kyle made me think of a new wrinkle to the change in the process when it comes to versioning.
When Dr. Kyle defined versioning, it made me remember that there are different versions within the SDOs themselves.
Right now, X12, for HIPAA transactions, is 004010, but I believe the attachment is offering the 004050. So, the wrinkle that I am wondering, if it would be most appropriate to be answered in the proposal of a change in the process that we heard from the industry earlier, if, in fact, there is a proposal for how those versions within the X12 HL7 would be handled across the board. So, if you have an 837, you have an 835, you have a 270, 271, are they all going to be the same version?
MS. GOSS: At X12 we have been working on a rotating schedule, where we are updating what we call our HIPAA-esque guides. We call it HIPAA-esque because it hasn't been adopted yet.
So, we have a suite that we would expect to move forward, and we are on a two-year development cycle currently for everything, from pre-authorization to the remittance advice to eligibility, all the ones you mentioned plus some, so we could move it forward.
MS. BURKE-BEBEE: That is great in that bucket, but when you have NCPDP and HL7 and the relationships with the MOUs and so forth and so on, what would be the process where there would be harmonization so that we have interoperability. We don't have to solve it here, but it just made me think, even larger, what the process would entail.
MS. GOSS: It is a good point, and we are using our liaisons, and we are using cross work group members to address the needs of taking an NCPDP claim and being able to reply with a remittance advice that uses an X12 standard, to make sure that their needs are met.
MS. BURKE-BEBEE: I appreciate that, but I am talking long term. So, when the issue and the problem are resolved now, a year from now, will there still be a relationship. If that needs to be a formal process, whether it is formal or private?
MS. GOSS: We, as HL7, NCPDP and X12, have all created formal memorandums of understanding to have a long-term committed relationship to do the right thing for the industry, to meet our constituents', or our stakeholders' needs.
The relationships that we have been forging have taken us some time, they have grown, they are healthy, and we have these exchanges going on, and we are thinking long term.
The work that we are doing now is feeding into the health information technology standards' work, which is part of the ONCHIT contracts.
We are here to meet the stakeholders needs. That is our business as SDOs. So, we are going to work together on a long-term basis to provide the solutions that allow information to be exchanged.
MS. WARREN: I had two kind of questions. One is, I am trying to understand the proposal that you are bringing up, having the public comment that the SDOs provide in the passing of standards, and having it be linked together, either replacing the NPRM or doing it simultaneously, or some other kind of process.
The concern I have is, being a member of two SDOs, in fact, is that for me to give public comment on a ballot, I have to be a member. On some of them you do.
I think that would be a challenge, to figure out how you would open this up and get comments on the ballot and have to do that, or to put a public comment period that is not attached to a ballot passing. That would be one things that I think we need a little bit more clarity on.
MS. GILBERTSON: There might be a communication issue or something like that, but I believe very strongly that our ANSI accreditation says, any materially interested party may comment at the stages that have been established. That would mean Joe Blow off the street has just as much right to comment as a member.
MS. WARREN: I think that would be one thing that would make this a little bit more open and accessible, if there were times that you said, this is when it is open for public comment, whether it is during the balloting process or prior to that or whatever. So, that would be one of my requests, to clarify that.
The other one I had -- and I don't know whether I can -- maybe I can't put Stanley on the process -- we have heard from them that one of the problems they have is that there is no predictability for when an NPRM is going to come out. So, that lengthens the process. I was just wondering if that is something that can be looked at managed to provide some predictability.
MR. NACHIMSON: The issue is, there is no predictability in the entire regulatory process from start to finish, not only when the NPRM comes out, but also when the final rule comes out.
We certainly have looked at that, but the management of that is dependent on so many factors, not only the minor factors like resources within the agency, but the length and breadth of public comments, the particular type of comment that comes in, the controversy about an issue, the policies of the agencies and the department.
We have very little control over even something as minor as our general counsel's time. There are conflicting priorities. So, when a regulation goes to the office of general counsel, while we may consider that, gee, this is a HIPAA issue, it is incredibly important to the industry and the SDOs, and everybody agrees on that, there may be very well another issue of greater importance to the industry, to the department. So, the general counsel's office will say, we will get to the HIPAA issue next month or the month after.
So, there are items like that, that are very much out of our control, and I don't mean to pick on the office of general counsel.
DR. WARREN: It just seems counterintuitive to administrative simplification.
MR. NACHIMSON: Unfortunately, under the APA, I guess, there are no requirements for how long an agency gets to publish a proposed rule, although there are some requirements for Medicare, that they have to issue a final rule, I believe it is within three years of publication of a proposed rule. That is not a very short period of time, but I think that is a sense of what you get.
MS. WARD: If I may, just in response, I want to echo what Lynne said, at least from an HL7 perspective. You don't have to be a member to vote on a ballot.
There is a fee in HL7 to participate in a ballot, in a vote, if you are not a member, but my experience has been with HL7, with the organization itself has been, they have always been more than willing to talk about whatever they need to do to come to compromise with us, in working with HIPAA.
DR. WARREN: It is exactly the charge or the fee to participate or to be a member that I think may be a road block. To respond to an NPRM, you don't need to pay a fee or anything like that.
MS. WARD: The fee, for a non-member to vote, just so you know, is $25. It is not like the membership fee. My last comment there was to say, if we were asked to reconsider that, and to think about it in a bigger picture in the context of changes to the regulatory process, I am sure we would be happy to do that.
MS. GREENBERG: I am back in the weeds a little bit here, but in listening to the testimony, it seemed to me there were a few areas where there wasn't complete agreement, and I just wanted to clarify that or see if I missed something.
I thought I heard Lynne proposing that we also do away with the DSMO process, but I didn't hear either Alix or Maria proposing that. So, I wanted clarification on that.
Then Alix, I believe, said that sometimes you have to remove functionality from a previous standard, and I think Maria said that you should not remove any functionality. I wondered if there was a differing view or just a different interpretation or definition. Those were my two rather technical questions.
MS. GILBERTSON: The first one you are dead on. When NCPDP was involved in these many years in trying to find solutions, the DSMO is a great structure for bringing comments together and discussing them.
I think the industry has shown that they don't need the DSMO any more to do that. The DSMO gets very few change requests any more.
They are coming through the SDOs. So, the public is learning that, or the public is waiting until there is a threat of another NPRM before they get all those put in. Who knows.
I think we have shown that the content committees in the SDOs are collaborating at a level maybe ever seen. I don't know that far back, but they are.
Therefore, that was a suggestion intentionally. We could leave it in as a process, but I am not really sure that it adds as much as it did years ago.
MS. GOSS: In regard to your comment about backward compatibility, I want to make first a distinction before I fully address your question.
In the X12 world, there is a standard, and then there is an implementation specification. The standard does have backward compatibility, in that we add onto it. We don't tend to take away from that base standard. Codes are a different dynamic but, for the most part, we do not. We add on.
When you talk about an implementation specification, it is a subset of the actual full standard. That specification will be modified based upon the different changes that come out from the industry.
For instance, NPI, we couldn't handle in 004010 to be compliant with the policy. So, we had to modify 005010. In that case, the implementation specification is not backward compatible.
MS. GREENBERG: In response to what Lynne said, does X12 still see the need for the DSMO process?
MS. GOSS: I think the DSMO process provides us with an additional layer of industry involvement from the data content committees. As you did hear, ADA does participate. We do have other representatives there from other data content committees.
I think I have mixed opinions about it. I would really like to see everybody come into the X12 process and sit at the same table, and us work through that at that step, and then go through our normal public comment period to get a validation.
I do think that the industry knows about the DSMO process, and they will, when they see further changes coming down the pike, like 005010, hopefully will be adopted, that will cause another flurry of activity to get change requests.
We are processing not even five a month, compared to the thousands of change requests we are getting in the SDO process.
So, do I think it is adding a lot of value? In the development process, no. Do I think it has been a good discussion forum with OESS to address some of the over-arching HIPAA problems? Yes.
MS. WARD: Just from my perspective about the DSMO, you are right, in that we did not remove that in what we proposed to you today, and I think for two fundamental reasons.
The first is, that is really not the issue. The isn't how much time that process takes. The issue is what we all have heard it to be this morning. So, we didn't see that as any sort of significant road block in allowing a more streamlined process.
The second thing is, echoing really what Alix just said, I think it provides another layer of industry input, which I don't know if it was Steve or Stan in the earlier panel this morning talked about, we removed this one part, whose primary function is to provide notice and input. How do we make sure that we are still allowing for that. I think the DSMO provides that.
At the same time, I think that, at least from my perspective, we are open to having discussions about whether or not it is necessary. I don't know, but for now I think it still provides a valuable means for input.
In terms of backward compatibility, I was reading you a definition, and that is HL7's definition and official position on what is backward compatibility.
Do I think that real world, is it always going to be, as we move forward, at least, in the context of what we are doing within the attachments group for HIPAA? No.
I mean, I think, real world, we might have a subsequent version where something is removed, or a different code set is referenced than was before.
So, I am not sure that it is going to apply as we advance versions of our standards within the ASIC, but that is the official HL7 position on that.
DR. HUFF: One of the thoughts that occurred to me, it sounds like, at least at a legal level, one of the problems is that the particular implementation guides were adopted by reference in the current NPRM.
One of the things that that started me thinking about, so we might be captured for one more cycle if we are going to change, but is there a way that we could structure, in a new NPRM, essentially to adopt the new process in the next cycle, so that we don't include them by reference.
We could then -- so we would be stuck for one more cycle, but we could do something where we could generically refer to them, describe in detail the process that has been proposed. So, then we would be out of that cycle, once we had completed it one more time. Is that something that might be feasible?
MR. NACHIMSON: My retainer ran out. I lost my attorney. I appreciate that suggestion. That is exactly what we are looking to do in the NPRM that we are talking about for next year, trying to figure out a way to give the department some flexibility within the context of the implementation guides.
Whether that means -- that is, again, something we are continuing to explore with our office of general counsel, adopting an 835 version 004050, let's say, and letting the implementation guides, letting them continue to evolve, as long as they still refer to a particular version, or maybe, let's say, adopting an X12 835, and letting the versions go on. That is a suggestion that we are trying to work out with our general counsel.
MS. GOSS: We have discussed this concept of adopt the X12 835 and leave it at that. Don't get into implementation specification levels or versions of the standards.
If you do that, you are just kind of replacing one problem with another. You still need to let the industry drive the needs and the implementation specifications that are driven off of functionality. If you specify down to the version of the standard, you have just pigeonholed yourself all over again.
MR. NACHIMSON: We are exploring it. We are certainly ont at this point ready to say that is definitely the way that we are going to go. We are just in the process of trying to work it out.
MR. REYNOLDS: A little housekeeping. It is 12:05. I am going to allow a five minute biobreak. I at least need a quorum of the subcommittee to return at 12:10, and that will give a chance for the next panel to set up.
So, we thank you very much, excellent testimony. We appreciate that, in some ways, you differed, too, because there are many views on this. So, thank you very much.
[Brief recess.]
MR. REYNOLDS: We would like to go ahead and start the next panel. Continuing our discussion today, we are going to look at the plan perspective.
We have, from Blue Cross and Blue Shield Association, Alissa Fox, and we have Dale Chamberlain from Express Scripts. So, we will just go by order of the agenda. So, Alissa?
Agenda Item: Updating HIPAA Standards: The Plan Perspective.
MS. FOX: Thanks very much. My name is Alissa Fox, and I am vice president, legislative and regulatory policy of the Blue Cross Blue Shield Association, and thank you very much for the opportunity to discuss our comments today on proposed revisions to the HIPAA standards development process.
We agree 100 percent that the process needs to be improved and streamlined, and commend the committee for examining the issue today.
We have four recommendations for improving the process. First, we recommend that the entire process, from when an SDO first identifies a possible need to create or change a standard, to when a regulation is promulgated and implemented by the industry, be reviewed, to eliminate unnecessary steps and delays, in order to make the process as efficient as possible.
The industry needs a reasonable predictable maintenance cycle to be able to pay for and deliver health care in the most efficient way possible.
Second, we recommend that, as a prerequisite, only those standards that will be adopted widely by providers should be adopted as HIPAA standards.
As you know, today the standards are mandatory for payers, but voluntary for the provider community. We would say that you need to look at this for both new standards, as well as modifications to existing standards.
If providers are not likely to use the standards, nobody benefits. The payers' experience to date has been build it, and they will not necessarily come.
We know that the majority of providers are still not using many of the HIPAA transactions, including the standard remittance advice eligibility claims status, all of which have the potential to produce a positive return on investment, by reducing paper, printing, handling, mailing costs and telephone calls for both providers and for payers.
The detailed statistics on this are in my prepared statement, and we urge that, before new transactions or new versions of transactions are adopted, a critical examination be undertaken of whether providers will use these new transactions and, if not, why not. What are the barriers for them adopting this.
We believe two strategies should be examined. Let's address what those barriers might be, make sure those standards reflect the reasons why a provider may not want to use the standard.
Maybe it is not very helpful to them. Maybe it requests information they find burdensome. So, let's address that.
Second, we need to look at possibly providing incentives for providers to adoption, and possibly even requiring these transactions for medicare.
It is also really important that vendors incorporate all the new standards into their systems to assure that the provider adoption needed to achieve the full benefit envisioned.
If analyses show that a standard should be adopted or updated at all, then all industry partners, including vendors and providers, should be using the standards. That is the only way this system will work.
Third, we recommend that consideration be given as to how we can develop materials that are more readily understandable by industry stakeholders, other than those actively involved in the technical work being done at the SDO level.
We need to really -- a huge challenge is how do we engage senior executives at both the payer and provider organizations to pay attention to this, especially because so many of these standards require business process changes and impact policies at these organizations.
This is needed to assure that all entities know the job at hand, so they can get it done efficiently. They get the budget, they get the time frame, they know what to do, and they can get it done on time, so we get the benefits for everybody.
We believe that not having that kind of information was a problem, and that is why it took five years, and even more than five years, to transition to the new HIPAA standards.
I know, when I first started back in 2000 looking at the HIPAA transactions, and not being a technical person, there was information at this level, a very high level, which I really didn't understand what does that mean, if you need to adopt it.
Then someone said, well, look in those implementation guides, and I printed them all out. Like I had 12 different binders, and I took them home, and I am going to figure this out.
Not being a technical person, it didn't mean much to me. There was nothing in the middle that you could look at to explain what was really different here. How was a claim different from the claim that people used, what more information was being requested or not. That is the kind of information I think is needed for everybody.
Finally, we recommend that pilot studies be done on any major HIPAA standard before it is adopted, and we really commend this committee for recommending that in the past.
We believe the claims attachment pilot, while it was only for medicare, we think it really was helpful, it highlighted some key implementation issues that are now being resolved.
So, when the claims attachment comes out, we won't have those problems. We have identified them, we have fixed them, and we can move on.
I also have two comments on some of the proposals being considered that you have heard this morning. First of all, we don't really believe that CMS' new process for version updating electronic prescribing standards is appropriate for HIPAA because of concerns about how you define backwards compatibility.
We believe the changes involved in a modified version of HIPAA are so extensive that backwards compatibility is just not attainable.
We have looked at 004010 versus 005010, and have some very specific, concrete examples in my written statement for your consideration why we don't think that works, and some of the technical issues involved.
Secondly, we think it is a concern about just dropping the NPRM process. Today, that is when people really look at this. Whether they should or shouldn't be, that is what is happening today, and that is when policy and business issues are being highlighted.
I think the vendors said, they don't even look at it until the final regs come out. I think that is a real challenge that we all have.
What our experience has shown is that, until you know what the work at hand is, and you roll up the sleeves, actually after the reg is finalized, do you really understand all the things you need to do.
We need to figure out a way to move that up. It can't happen when the final reg is implemented. We have got to move it up sooner, and I don't have the recommendations here today, but that is something we are going to be looking at.
How can we figure that out sooner, so that we are really looking at this issue with more knowledge up front. Buy in, from the senior management level, we think, is really critical here.
Thank you so much, and we really offer our assistance as you look at these and other issues, and thank you.
MR. REYNOLDS: Thank you, Lisa. Dale?
Agenda Item: The Plan Perspective.
MR. CHAMBERLAIN: Mr. Chairman and members of the subcommittee, on behalf of Express Scripts and myself, I do want to extend my appreciation for this opportunity to testify this afternoon.
My testimony is really going to be in the form of this presentation, and I think you are going to hear a lot of common themes from the previous testimonies as well.
Starting off, the common thread here is that the needs of the industry have surpassed what the current HIPAA standards provide.
In our particular business, we rely heavily on the NCPDP telecommunications standard version 5.1. That was approved by NCPDP in September 1999, which was implemented under HIPAA mandate four years later.
It is now six years after that standard was approved, and other mandated standards are of similar age. We are looking, at the present time, at years before a new standard is going to be implemented.
In the meantime, industry is suffering. The industry needs have evolved. We have had, obviously, with medicare part D, has made a major set of changes to requirements of how the industry needs to act.
We have had newer versions of standards which cannot be implemented because of the current mandate, that more fully address some of the needs of medicare part D.
We have also gained a great deal of experience from the use of the current standards that have been reflected in revisions to implementation guides that, again, we cannot take advantage of because of the current restrictions on the mandate.
You take that, and you put on top of that the initiatives of health information technology and MMA, have a lot of overlapping requirements.
Obviously, with HIPAA, we have the transaction code sets, security, privacy, standard identifiers, but now we have the community that is driving priorities on electronic health records which also have components of health insurance coverage, privacy, medical history.
Then medicare part D, as I mentioned earlier, e prescribing with medication history requirements, formulary and benefit, which tie back to insurance information, and then the coordination of benefits.
All of these things overlap and, as time goes on, they will continue to converge. What we can't have is process that will cause any one of these initiatives to impede the others. These need to be thought of as happening in synchronization and concert.
That brings us to the SDOs. We definitely agree that the SDOs have, in the past, and currently do, provide the forum for industry improvement.
This is where all the industry experts and the leaders have come in to express what issues are faced, that the industry is facing.
We have developed solutions through these forums. NCPDP, as an example, is a preeminent SDO for pharmacy services.
If you look at the others, they deal with other aspects of health care, but in the pharmacy area, which is where Express Scripts really spends its time primarily, we participate in NCPDP.
Payers, processors, providers, vendors, pharmaceutical manufacturers, they all bring their issues to this forum, to develop the solutions which advance the industry. This has been a proven, mature process.
Now, the industry, working with these SDOs, is very effective in determining what those implementation plans need to look like.
I think that we have to recognize what works, what doesn't work. This is an area that does work, and we should continue to leverage this in adopting new versions of the standards in the future.
Now, what has been the cost impact? Well, the first one that I want to bring to everyone's attention, that has already been mentioned in earlier testimony, is that work arounds typically become what happens.
If you cannot get your standard that is going to solve your particular business issue implemented, then you are going to use what you have and figure out ways to get around it.
Now, what happens is, this obviously undermines the advantages of having standards in the first place. You have a lot of one on solutions.
When you have these one on solutions, you start to inhibit interoperability. So, the longer it goes, the more inoperable systems we will be faced with.
The economic impact of the implementation of new versions of standards could be absorbed more easily using a routine and predictable adoption process.
By that I mean, if you look at the organizations today that have to utilize standards, I don't see where those processes, those planning processes today, involve any aspect of thinking about standards.
We are certainly not going to be investing in new standards development if we don't believe that is going to be enacted upon in some sort of regulatory fashion.
So, what happens is, it builds up, and it builds up over time. Then, once it finally becomes part of a regulation, then it is the big bang effect and it results in what I call version shock.
We talked about the executive level, the budget approvers not being involved. Well, they get involved when it becomes this event.
Then it becomes a question of why in the world do we have to make this type of investment. So, if you spread this out, make it a more predictable process, then you to smooth those bumps in the road. You start to smooth that versioning shock that is out there, and it becomes part of a routine that every organization embeds into their DNA.
So, this is a recommendation that I am going to be making here, that kind of takes a little bit of what we have been hearing, maybe kind of looks at it as a compromise solution as well.
Continue to allow the industry to utilize the SDOs to recommend new versions of the standards and, along with that, the time lines.
Utilize the version release methodology, the packaging of solutions, industry solutions, to be released in the next recommended version of a standard.
This recommended version doesn't necessarily have to be one that is currently approved by the SDO, I will get into that a little bit more.
The recommended version would become an SDO ANSI approved standard prior to the mandated industry implementation date.
Now, this recommended version could serve as a trigger to HHS to issue an NPRM. Now, you are not hearing me say we need to eliminate the NPRM, but what you are hearing me say is that we need to modify it. I think we need to streamline it. I think we need to cut some of the time impediments out of this.
Continue to leverage WEDI and the SDOs, working together with HHS, in the development of the NPRM. WEDI could act as an advisor to HHS on issues raised during the comment period.
Industry, through the SDOs, would continue to work through WEDI. The standards and implementation guides would be corrected during the comment period before the final rule is issued.
So, hopefully by the time a final rule is issued -- and I am saying that we need to impress that time frame between the time that the NPRM comes out, and when the final rule is made.
During that time is when you have the comment period and the final approval process. In effect, this would be like making the serial steps that we see happening today more in parallel, through multi-threading.
WEDI SNIP would continue to provide industry oversight and coordination in the implementation process of new versions of the standards.
I don't know if you can see that one, I put a little graphic up there to kind of show you the flow that I am laying out there.
Now this is high level, and the devil is definitely going to be in the details, but I think the key point to take away on this is making this more of a parallel process and less single threaded, and to allow for the recommended version to be named before it goes through the approval process, and to leverage a common process for the public comment period.
So, in summary, the current process is too slow to accommodate the needs of the industry, Medicare part D and other HIT initiatives.
The industry works with SDOs today to develop timely solutions and we need to continue to leverage that. The industry bears unneeded costs and loses the ability to spread out investments because of the time void between versions.
The process must become predictable. A more predictable and timely process will foster interoperability. Thank you.
MR. REYNOLDS: Thank you to both of you. Questions?
Agenda Item: Questions and Answers.
DR. STEINDEL: Alissa, I have a question for you, and this concerns your comment regarding the NPRM. In your statement you said that -- there were two parts, really, that I saw to the statement.
One was that industry really doesn't comment until there is an NPRM. The second part of the comment was that they don't really even act until there is a final rule and, in many cases, they are not paying attention until that point.
My question to you is, do you really mean that they don't comment until there is an NPRM, or the only reason that they comment during the NPRM period is now is the time when comments are going to be heeded. If we actually change that period, they will comment during the other period.
MS. FOX: What I meant was, that I think you are seeing comments being explained to you. For example, we have a lot of people at the SDO levels, and participate broadly, and I know the providers do as well.
My observations have been that it is really the technical comments that are being done at the SDO level, and what you are seeing at the NPRM process is, you are seeing more business and policy issues being raised during that process.
It is very different. Is it the right priorities, for example. That is the kind of thing that CMS is going to look at.
You know, I have all these HIPAA standards coming through the process, but given everything that the industry has, what do I do first, second, third and fourth? Do I do the claims attachments? Do I do conversion to the 005010?
You need a place to vette all of those issues. I think we all need to do a better job in looking at getting the right people to be looking at all of these issues.
I think that is a challenge in all of this, because a lot of what sounds technical has huge implications for payers and providers that don't get fleshed out.
What I was really trying to say -- maybe I didn't say it very clearly was -- the SDOs, I think people are really looking at data content and format issues, and the policy and business issues really get highlighted during the NPRM process.
DR. STEINDEL: That was a very good clarification. Thank you very much.
MR. REYNOLDS: Dale, I have a question for you, two questions, and I guess it is going to bear on this letter that we are trying to put together.
You talk about the NCPDP, telecommunications standard version 5.1. Is that different -- is that a version 5.0 or what?
MR. CHAMBERLAIN: You are talking about the NCPDP script.
MR. REYNOLDS: Okay, the reason that is important is obviously that we are about to write a letter to the secretary talking about nobody may have done something with 5.0, but yet -- okay, that is a good clarification.
The second, so far today, as I have kind of kept tabs, some people have recommended eliminating the DSMOs, some have recommended getting rid of the NPRM, and some have recommended getting rid of everything, some have recommended reworking it, and you appear to be recommending getting rid of us, very clearly in your testimony and your chart.
MR. CHAMBERLAIN: Don't construe the absence there.
MR. REYNOLDS: I am looking at your charts and I am looking at your process, and all I am trying to understand is how does that part of the process work, because you now have WEDI working directly with HHS to do these things. That is all I am trying to understand. I promise you, it doesn't bother me that you are trying to eliminate us.
MR. CHAMBERLAIN: Actually -- this is where I say some of the devil comes out of the details, and this is intended to be high level, but where I am looking at is many of the interactions here with HHS I would see as coming through NCVHS.
WEDI's role I see as being more of a coordinating function with the SDOs. So, if there is a new NPRM that would come out to name new versions of multiple standards, such as an X12N standard or an NCPDP standard, that coordination could take place through WEDI. Any other communications, both ways, with HHS, I would see coming through NCVHS.
MR. REYNOLDS: Even if you made it up, thanks. Any other questions?
DR.COHN: Alissa, first of all, thank you very much for joining us. Being someone who deals a lot with policy issues, I share, I think, concerns in these issues about HIPAA.
I know, when I think of my own organization, which is Kaiser Permanente, that we have lots of people involved in these processes, but as you commented, they are typically the technical people.
Usually, when it finally rises up to an NPRM or whatever, suddenly you get strategic and business people and all of that.
I mean, to me it is kind of a conundrum. I guess I am wondering -- I know you are looking at all of the issues, but do you see a way of getting more strategic input into this process in an earlier fashion? Do you think that is possible, or do you think we are just all trained to just look at NPRMs?
MS. FOX: I think we need to figure out how to do that, and I don't have the answer today, but we would like to come back and submit some ideas.
I think that is really a key issue here, that we need to figure out how to get more of the right people looking at things, not that the wrong people are looking at it, but we need more of the people looking at things, these issues.
I know, in our own organization, the only way we end up figuring out in our plans is when we hold meetings and we say, okay, we want you to bring your medical policy, your actuarial, your contracts, all these different people that don't talk to each other a lot of times, put them in the room, and then they say, oh, that impacts me, that impacts me, and this impacts me.
Until they do that kind of thing, it is hard to figure out some of these things that seem technical and seem not an issue, until you kind of see all the ripples, because these things tend to have such a huge rippling effect on the organization.
We would like to come back with some ideas on that, because I do think it is so critical to do it earlier in the process, so it is not slowing it down.
We agree with the objective here, that it is not working for people because things are taking way too long, and we need to look at how to streamline it. So, we would like to come back with some thoughts on that.
DR. STEINDEL: This is kind of a follow up on both your comments and Simon's comment that sort of goes hand in hand.
The understanding that I am getting from the two of you is that it may be difficult to change this from a biphasic process, which is what it is today.
There is the SDO work, which creates a technical solution, that there is a set of skill sets that are involved with that, and it creates an implementation guide that resolves certain technical issue.
Then there is also a business process that really can't be approached until you know what the technical resolutions are.
I don't see how this can occur except in a biphasic process, which we may be able to accelerate, but could you comment on that?
MS. FOX: I think that is what we need to look at. I don't have the answer today on that, but that is exactly what we are looking at. Can you do it simultaneously, does it have to be sequential, how would you do it.
I thought you had an interesting suggestion we would like to look at, that we would like to get back to you on that.
MR. REYNOLDS: Isn't the trigger, now it is real? I mean, standards organizations are usually working multiple versions ahead.
The NPRM, regardless of good, bad or indifferent, regardless of whatever is decided by everyone, now it is real.
I think we heard some testimony today from some of the SDOs on how to identify now it is real earlier in the process, and then it -- everybody right now, when it is NPRM, the game is on. That may be what we are kind of hearing in general, now it is real.
MR. CHAMBERLAIN: If I could add a comment, too, part of what I was saying earlier is that, by making this a predictable process, i think you start to then see, in the various organizations, this is something we have got to start planning for. We have got to make it part of our routine.
Right now it is not part of the routine. When you start to make it part of that routine, then you start to get all the people in the various parts of the organization to think about this.
MR. NACHIMSON: I just did want to say, in response to Dale's proposal, that we and the SDOs, CMS and SDOs, tried for months to figure out how to overlap the NPRM and the SDO common process, and to this date we haven't quite worked that out, but it is nice to know that that seems like it could be a viable approach, and we will keep attempting that.
In regard to this sort of predictability, one of the arguments we have heard against that -- and I think it is more from the provider perspective -- it is like, let us implement the standards once, and then leave us alone, for not a year, not two years, but for like five years. Let us get this done, and that is it.
I think that is some of the problem that we faced with the updating of the standards. Like Lisa, I don't know the answer to that question, but that is something else that we are going to have to build into this process.
Regular updating is something that we certainly understand that the standards organizations do all the time. The implementation process is something that a lot of people are resistant to doing any more than once in a blue moon, for that matter, but once every four or five years, as opposed to on an annual basis.
MR. REYNOLDS: Thank you very much. We really appreciate your input. Thank you. Our next panel is covering a number of subjects.
Even though she is not on the list, I think she had to be up there three times. I think her boss made her be up there three times. So, Lynne is going to do something.
Then, Lisa, I believe you are going to talk about -- what are you going to present on?
MS. MILLER: I am going to speak about the survey, maybe that middle tier that we were just talking about that is missing.
Agenda Item: HPIAA 835 Transaction Update.
MS. GILBERTSON: My boss is the DSMO, and the DSMO requested, they are on the agenda as DSMO discussion, and this is to set the stage for the information that Lisa is reporting, so that we can draw on what was requested in the past, and now where it stands.
So, this is the HIPAA DSMO letter that you all should have a copy of, addressed to Simon.
In 2004, the DSMO received a change request that sought our approval for the adoption of a newer version of the existing HIPAA electronic remittance standard implementation guide known as the 835, version 004010, 004010-A-1.
We reported last February that the DSMO supported the request to move forward a new version of the 835 health care claim payment/remittance advice.
Our recommendation was based on a qualitative review of industry input, which indicated that the 835 version 004050 implementation guide incorporates needed improvements to provide for a more effective and consistent implementation of the standard.
Shortly before our February report, we were advised by the office of E health standards and services, formerly known as the office of HIPAA standards, that it would be necessary to develop a cost benefit impact analysis for inclusion in any NPRM.
Consequently, we sought to develop a process capable of requesting the collection of supporting cost benefit information from various industry organizations. The purpose of this letter is to update you on the status of this charge.
The DSMO did not feel it had the resources to undertake such a study. Therefore, we solicited the help of the work group for electronic data interchange, WEDI, to aid in the designing and conducting of a cost benefit study related to adopting the 004050 version of the 835 as the successor to the 004010-A-1 835.
Additionally, we asked whether WEDI would be willing to provide continued assistance for assessing the cost benefit for future HIPAA standard modifications.
We explained that these impact analyses would be done during the pre-NPRM phase, and included as part of future NPRMs.
To help ensure smooth and timely transition to standards, a predetermined approach for both minor and major modifications would help the DSMO in their deliberations.
WEDI formed a task group during the summer of 2005. As a result, a web based survey instrument was developed and widely publicized.
The survey was designed for a quick turn around and tailored according to the respondent type, health plan, payer, provider and vendor.
A total of 165 valid surveys were submitted. Interpretations and findings were summarized according to the three categories above.
The task group compiled the results and issued a report. The report lists various benefit opportunities for providers, payers and vendors, but contains no specific recommendations regarding whether the 004050 should go forward for adoption.
The complete report, entitled, 2005 survey, health care claim payments/advice version migration is available at the WEDI web site.
OESS lent support, and provided input throughout this process. We understand that the results of this survey work product will assist CMS with drafting the impact analysis for the NPRM.
The public will have an additional opportunity to comment on the results, and implications of this survey, as part of the regulatory process.
The DSMO steering committee wishes to assure the NCVHS that nothing has come to its attention that would preclude consideration of the 835 version 004050 implementation specifications as a HIPAA transaction for remittances to supplant the current 835 version 004010, 004010-A-1.
We also wish to advise NCVHS that a newer version of the 835 standard, the 005010, has been approved by X12, and is now going through the final publication stages.
The 005010 contains additional guidance on how to implement the standard, and is not dramatically different than the 004050.
The incremental change from 004010, 004010-A-1, to 004050 is more significant. Accordingly, the DSMO steering committee encourages NCVHS to proceed with a recommendation to HHS to begin an NPRM naming the 004050 835.
The notice should include a request for comment on whether the 005010 version should be adopted instead of the 004050.
Again, the 005010 does not represent a substantive change from the 004050, and if public comments indicate that the 005010 would be preferable, the final rule could go on to adopt version 005010 of the 835.
Now that WEDI has established a process to survey the industry on changes to the standards, it is quite possible that supplemental impact analysis of switching the standard to the 005010 would be available in time for the NPRM and certainly before the final rule.
Sincerely, Tom Ahmanson, chair, representing the DSMO steering committee, and Lisa will now present the survey.
Agenda Item: DSMO Discussion. Cost/Benefit Analysis.
MS. MILLER: Mr. Chairman and members of the subcommittee, I am Lisa Miller. I am the chief operating officer for Washington Publishing Company, and the chair of the work group for electronic data interchange, DSMO, CMS, and its cost benefit analysis task group.
I would like to thank you for the opportunity to present testimony concerning the findings of the task group regarding the potential cost and benefits migrating to the ASC X12N version 004050 835 health care payment advice.
In June 2005, WEDI was contacted by the data standards maintenance organization, DSMO, and the Centers for Medicare and Medicaid Services, CMS, to request assistance in the development of a cost benefit analysis that are included in every notice of proposed rule making, NPRM.
WEDI was approached due to our role as an advisor to HHS as prescribed in the HIPAA legislation. WEDI formed an ad hoc task group and developed a survey of the industry with specific questions for health plans, providers and vendors.
That survey has been provided for you in your packet today. I will present the survey results shortly, but first I will set some parameters around the survey, and more important, around the issues of the industry adoption of the 835 remittance advice standard.
WEDI recognizes that the true problem we are addressing with the 835 remittance advice transaction is not fundamentally a versioning issue, but rather an adoption issue.
Previous communication to HHS from WEDI -- and we are referring here to the WEDI letter to Tommy Thompson dated March 8, 2004 -- identify adoption impediments that we believe are more significant than the version issue in this case.
WEDI's recent paper summarizing our survey on the costs and benefits of moving the 835 transaction from version 004010-A-1 to version 004050 reports industry belief that there is value to migrating, but starts short of establishing certainty around the return on investment for payers and providers.
Other WEDI deliberations at the board level have elicited industry opinions that there are more serious barriers including:
Perception of reality of an adequate specificity in the code sets utilized by both the 004010-A-1 and the 004050 versions of the 835.
For example, the reason codes and the remark codes, both of which are external code sets to X12, and can be amended by the coding bodies without HIPAA rule making;
The COB/Medicare crossover inadequacies; and perception or reality of balancing problems within the 835 or between the 835 and the 837 claim.
The bottom line is that the industry use of the 835 is low, and is not likely to grow significantly until the 835 can assure users that posting and closing can be automated within the provider practice, and that most adjustment clarification phone calls between provider and health plan can be eliminated.
WEDI is working with its membership and will be working in cooperation with X12, the coding committee, CMS, and other DSMO organizations to address those barriers.
That being said, I would like to now focus on WEDI's 835 version 004050 survey and results. During the June 2005 conversations with the DSMO chair and OESS staff, the following were identified as items that would be both meaningful and as accurate as possible. The items identified were:
The organizations were initially looking for a cost benefit analysis for moving the industry to the 835 version 004050;
Costs and benefits should be reflected for each covered entity, including payers, providers and clearinghouses;
The information would not need to be statistically valid but, rather, could be based on industry estimates from each of those core stakeholders mentioned above;
When information is estimated, the NPRM would likely ask for industry validation to agree with, or dispute, the estimates, and provide for additional information gathering prior to the final rule.
Creating the analysis will help CMS expedite the timing and release of the NPRM -- that might be something that is near and dear to our hearts today;
And need the analysis completed by the end of July 2005 for the 835 version 004050.
In order to meet the aggressive time requirements, WEDI did create the task group that consisted of a cross section of industry stakeholders, including payers, providers, clearinghouses, vendors, standards liaisons, including DSMO representation, government liaisons including the CMS, OESS representation.
It was further communicated that in the future the DSMO CMS representatives would require cost benefit analysis for additional NPRMs, for example, when it is recommended to move forward with the X12N version 005010 transaction sets.
The first organizational meeting of the task group occurred on July 13, 2005. During this meeting, the approaches to meet the requirements and deadlines were discussed.
The task group agreed that a survey of the stakeholders would be the most efficient method of obtaining the industry perspective.
The task group also agreed to utilize the X12 document, health care claim payment version 004050 cost benefit analysis, authored by the X12N TG2 work group three, claim payment work group, co-chairs.
It was further assessed that the group could not make the July time frame, and adjusted the time frame to the end of August for the completion of the document.
The announcement, survey questions and the X12 document were sent out to the community on August 3, 2005. .With the assistance of the American Medical Association's online survey tool, the survey results were collected electronically and closed on August 10, 2005.
The survey results were analyzed and compiled into the document that you have in your packet, titled, health care claim payment advice version migration, and was ultimately approved by the WEDI board of directors in September 2005.
The web-based survey asked participants to self select into one of three domains: health plan or payer, provider, vendor.
Please note. It is important to note that respondents did not necessarily answer every question in the survey. In addition, there may be some outlier responses that skew the response averages up or down.
The document which I have attached, which is a rather large document, has the actual results of the survey attached. I am going to read to you just the summary and the high level benefits. I will not go into the actual detail of the numbers.
Health plan -- payer -- interpretation and findings. The health plan - payer -- survey had 40 valid responses.
The summary of the responses and the detail of the responses can be found in the subsections called, payer survey summary, and payer survey results.
After evaluating the content of the 40 responses, the task group concluded that the survey results were substantially representative of the industry.
Findings. The 40 responses included representation from most health plan sectors, including federal and private payers, indemnity and managed care, acute and long-term care, dental and vision.
Ninety-seven percent of the responding payers are capable of sending the 835 today. Most of the payers, 69.7 percent, reported that fewer than 50 percent of their trading partners in the provider community were receiving the 835.
Average cost for the payer implementing the 835 ranged from $219,000 to $287,000. The average cost for the payer community is higher than the average provider organization cost.
There are unidentified costs that will raise the implementation cost for the payer community, i.e., companion guide creation and testing.
The benefit opportunities. We felt that there may be room for potential benefit for the health plan. The 004050 835 provides clear instructions, providing consistency across payers that may potentially lead to the improved usage of the 835 by their trading partners.
Although not specifically addressed in this survey, the increased acceptance of the 835 may reduce ancillary costs such as customer service, payer based payment and reporting, increasing the potential benefit by the health plan.
Provider interpretations and findings. The provider survey had 93 valid responses. Of these 93 respondents, 42 percent indicated that they are best described as a hospital, nursing facility, health system or other institutional setting.
Eighteen percent indicated that they were an individual or group of physicians, and 40 percent indicated that they were something other than these categories, including ambulance, lab, pharmacy, DME and all other clinics and practitioners.
The summary of the responses and the detail of the responses can be found in the sections, provider survey summary and provider survey results.
The task group evaluated the content of the 93 responses. The group observed that the survey sample was too small for statistical validity, and that the respondents were disproportionately representing large providers. Small groups and practices were not well represented.
Nonetheless, task group expert opinion is that the survey probably is representative of provider organizations who have implemented the 004010 835 health care claim payment advice.
Since implementers tend to be larger organizations, therefore we feel that the content is valid for the purposes of this study.
Our findings. Small numbers -- 93 -- of providers responded. More representative from the large providers, limited representation from the small groups and practices.
For the most part, the provider community that is capable of receiving the 835, the majority of the remittance items are still posted manually.
Average cost for individual or group physician respondents implementing the 835 consists of about 110 person days, plus about $48,000 for software costs. So, they were talking about man days for development.
Costs for very small provider groups and practices, less than 10 physicians, is unknown, since there were no small practice respondents.
Average costs for hospital, nursing facility, health system or other institutional settings, and other respondents implementing the 835 consisted of around 200 person days plus software costs of around $144,000 for survey respondents. There are unidentified costs that could raise the implementation for the provider community as well.
Benefits. There may be room for potential benefit for the provider. The 004050 835 provides clear instructions, providing consistency that may potentially lead to provider's ability to further automate the 835 where it is already in use with payers, and begin to use the 835 with more payers.
The 004050 version of the ASC X12N 835 may remove obstacles to industry-wide implementation of the 835 for reporting and posting of electronic remittance advices.
This implementation has significant potential benefits for both providers and health plans. One aspect of the potential 004050 835 cost savings would be better remittance management, secondary billing, and more timely generation of patient statements.
The task group has estimated that providers may conservatively save $4.00 per pay posted in an electronic versus paper environment.
The task group has identified other possible benefits, which include cash flow improvements, reallocating staff to other functional areas that impact operating costs, savings in paper management and storage, easier retrieval of EOBs for follow up purposes, appeals processes, if the 835 is stored in a file for future reference and other benefits.
Overall, enterprise management is impacted when cash is posted accurately and timely, and can be used to track the financial performance of specific treatment modalities and how they can be changed to increase overall performance, for example, eliminated, improved.
Finally, other regulations are creating pressure in the area of remittance management, to ensure that financial records accurately reflect fiscal posture.
Implementation of the 835 can streamline both operating and compliance procedures for the health care provider.
The ASC X12N 835 may require changes before it can be operationalized, including issues around the coding of denial reason codes and other areas.
As these issues resolve, implementation of the 835 to automate work flow processes could become just as important as the automation that has already occurred with the 835.
If the hospital administrator was ever faced with turning off the 835, it would create a strain at many hospitals because the savings have already been internalized. The 835 offers the opportunity to reduce costs related to the remaining remittance classes.
Vendor interpretations and findings. The vendor survey had 32 valid responses. The summary of the responses and the detail of the responses, again, can be found in the vendor survey summary and the vendor survey results.
The task group evaluated the content of the 32 responses. The vendor survey is unique, in that the customers of the vendors that responded are both providers and payers.
53.1 percent of the vendor respondents report institutional health care providers, 87.5 support professional health care providers, and 43.8 support payers.
These percentages add up to more than 100 percent, because the vendors could potentially support any or all of the categories listed.
The task group concluded that the survey results were representative of that industry, and the content was found to be valid for the purpose of the study.
Our findings, a small number, 32 vendors responded overall. We had representation from all vendor sectors. The majority, 83.3 percent of responding vendors, report their software is capable of receiving and sending the 835 today.
The majority of vendors, 58.6, receiving and sending the 835 report that usage of the 835 is less than 50 percent of total potential volume.
Reported costs for creating a new version of the 835 range from under $25,000 to $5 million. One respondent only for the $5 million.
Benefit opportunities. There may be room for potential benefit for the vendors through improved remittance capabilities, and clear instructions of the 004050 835, which may drive up usage of the remittance related products and services.
Although not specifically addressed in the survey, the increased acceptance of the 835 may reduce ancillary costs, such as customer support, paper based payment and reporting, and increasing the potential benefit.
In conclusion, while WEDI believes the survey results are reflective of industry beliefs, their survey stops short of conclusively demonstrating achievable value to the industry for identifying next steps toward the removal of all barriers to adoption.
We conclude that further exploratory work is advisable. This work should include: specific quantification of the 835 004050 adoption to providers and health plans;
Resolution or substantial improvement in the specificity and uniform use of code set; further refinement of barriers to automated posting and closing of accounts based on the 835 data; finally, further research to identify and address implementation barriers from all parties' perspectives.
Overall, the survey results indicate potential benefits for the migration from the 004010 to the 004050 version of the 835 transaction currently mandated under HIPAA.
The nature of the requests from CMS and DSMO methodology did not contemplate a quantitative proof of benefit.
I would also like to note that it was not in the scope of this task group to consider or evaluate other versions of the 835 such as the 005010 version.
Mr. Chairman and members of the subcommittee, thank you for the opportunity to testify. This concludes my statement.
MR. REYNOLDS: Good. Thank you to both of you. Open for questions.
Agenda Item: Questions and Answers.
MR. REYNOLDS: Turning to Lisa, the second page of your presentation and trying to play off of a lot of the things we have already heard today, if I go to the middle of that, it says, the bottom line is that the industry use of the 835 is low and it is not growing significantly.
Then it gets into where I guess my feelings are kind of gathering up about today, and it says, can assure users that posting and closing can be automated within a provider practice, and that most adjustment clarification phone calls between providers and health plan can be eliminated.
To back to some of the recent discussions, so there is an 835 in place, there is a 004050 ready to go, there is a 005010 getting ready to go, and there are two major business issues, that sit there, based on this document, and say, I don't know if it is going to help me and I don't know if it is going to reduce my administrative costs.
Back to our earlier discussions about whatever process we change to, making sure that these discussions are brought up.
The other thing is, I don't see anybody putting their hand up in the process to solve this, and I don't see any mechanism in place, whether it be from the government or anybody else, to solve these two questions.
So, as we look at the process, I am sure at some point there will be a 005020 and a 005030, but if these two questions don't go away, and these two issues don't go away, then how do we -- if I could take these two things just as examples, and you put them down, and put them into the process we were talking about earlier today, making sure that these kinds of things get dealt with, whether it is through the SDO process, through the NPRM process, through whatever process we all decide is going to be the new way to do it, appears to me to be as much of the crux of the battle.
People are going to be willing to go to the next version or do the other things once they see that it can happen. Then the lack of response also brings up that other point that, so there is a survey out there, do I or don't I answer and, if I answer, what does that mean or not mean.
I think that is the continuing thing that hits me out of what you had to say, that kind of fills in with everything I heard today. So, I would love any comments from you, Lynne, Ann.
MS. MILLER: Let me comment on a few things. One, one of the disappointments in the survey -- and I have to say, somehow I offered to be on a committee and ended up the chair. So, we will start there, and then stepped up and did this very quickly.
There was not much notification prior to this survey because of the time line, and I think that is why we saw some of the disappointing survey results that we did.
We put it out. I think they had to begin response within two days, and we closed it within seven business days.
That is pretty fast. I was amazed that we got the amount of people responding that we did, with a seven-day survey announced the first week of August during high vacation time.
I would suggest in the future that, one, we have more of a leeway for the task group to have a longer comment period open, and the surveys open for a longer period of time.
It would also help us to get the word out. We did very quickly, and I will say that the WEDI staff did an excellent job getting the word out as quickly as they did but, again, a seven day survey, which is what this document represents -- and that is why I gave you the history in the beginning of the document, so that you could see what my time line was.
We made the announcement on the 3rd of August. We closed it on the 10th. That is pretty fast. I think that really statistically tells you.
Now, on your second point, I think this is a missing chink in the process that you talked about today. Although I can't really comment too much on much outside of this survey because my role here is really to present this, but as the task group chair, we have moved forward to start looking at doing these same surveys with a longer period of time to help fill in the gap, to really start bubbling up to those business users, and to the community at large.
We are looking to move a version. What do you think. What are the issues that are out there. Get a more robust survey as well as raising the awareness in the community.
If Jim wants to speak to the pilots that WEDI is looking at, a good example would be the pilots around the acknowledgement task group, and moving forward with a pilots process prior to mandating NPRM or any kind of issue.
I think, looking at the two issues that we have raised, we really need that missing link, and this benefit analysis, prior to NPRM, really helps guide that NPRM process and gives Stanley what he needs.
MR. NACHIMSON: First, I really want to say that this -- to echo what Lisa said, this is an enormous benefit to CMS, and they are moving the process forward.
Those of you that are familiar with the regulatory process know that we have to have this impact analysis in there.
Frankly, when we are working on HIPAA standards, it is nothing that CMS has a lot of control over. We are not as familiar with provider operations and vendor operations as we might be with health plan operations.
So, it can be somewhat difficult for us to put together an impact analysis on the industry in something as complicated as this.
So, getting an outside organization like WEDI and the DSMOs to work with us to actually produce this information prior to the NPRM does speed up the process and really gives us a piece of information.
To your points about these other issues that were identified, to me, the move from the 835 004010 to 004050 solves some problems, not every problem, but some of the problems.
The benefit of this is that actually this survey actually identified additional problems that would not necessarily be solved by a version change, but clearly can be addressed through some other items.
The thing about the phone calls is because the new reasons codes that were adopted under HIPAA were not as specific -- and Harry, you probably know this as well as anyone -- not as specific as the individual plan codes that were in existence prior to HIPAA, even though they were proprietary.
So, we have to work, or the industry has to work through the appropriate reason code committee to get those codes updated and expanded.
For some reason, people didn't know that that actually existed. They figured, this is a HIPAA standard, I can't change it, I am stuck with it, and it has been a slow educational process.
I think it has been beneficial for a survey like this to point out not only the costs and benefits of the transaction itself, but other issues as well.
MR. REYNOLDS: The other comment I would have under provider interpretation, I have been hearing a lot of presentations recently on electronic health records.
You think about a remittance advice, which is really a transaction coming in to you and then you post it. The average cost right now from the main vendors for an entire EHR system for a single doctor is between $15,000 and $37,000 per doctor.
So, you are talking about an average $48,000 cost here to receive a remittance advice. So, we make it sound trivial in the spirit of what we have all spent on HIPAA, but when you look at that individual doctor -- one of our focuses as a committee has always been a doctor -- that is a big number.
That is a big number that will change going forward, because it is $48,000 for the first shot and now you have got to do the next version.
I think it is very important, especially as we look at -- and a lot of the adoption is the big players, and you said that clearly.
As we start driving this down to the smaller players, the better we can get at making it worthwhile, and actually not cost them as much to do, whether it is through the vendors or anybody else.
That is really going to drive adoption. Really, I think we are all about adoption, because if you don't get full adoption, you don't get the benefit.
So, it is funny. I have sat through three of these this week from national vendors on what it costs on a per doctor basis. It just kind of struck me when I saw the $48,000 plus the days, that that is a pretty significant number to an individual or a couple of doctors.
MS. MILLER To comment on that, I felt that data was very telling and important to bring forward, and I should give my background as a vendor.
It is really nice to go out and give your estimation, but to hear it and have it documented from the providers themselves, again, just gives validity to the value of doing this type of survey and this work prior to an NPRM, so that we can start addressing this, and working with the vendors through WEDI to say, how can we make this palatable to the provider community.
So, I look at this as a place for WEDI to move forward with more work efforts, to assist in our role and really build off of what we have gained.
These will grow and mature in the process that the task group has put together, to put these reports together, and hopefully you will be seeing us more often giving you reports.
MR. REYNOLDS: Thank you, we look forward to it. Any other questions?
DR. COHN: I guess I was just going to sort of comment that, of course -- following up on what you were saying -- I do want to remind others that obviously these numbers are not typically for individual physicians, since most of this was larger practices and also hospitals and things like this.
So, it may not be quite as bad. If you are a one or two physician practice, there is a reason why you probably haven't implemented it.
MR. REYNOLDS: The way it is stated here, is that the average cost for individual or group of physicians, that is the way they stated it.
MS. MILLER: That is how the providers came in and identified themselves. They came in and put themselves in a category and said, this is where I fit, and this is what we are telling you it is going to cost us.
Although we may not like to hear those results, and those numbers, I think it is our duty to report them as they come in ont the survey and be accurate.
DR. COHN: The other thing was, I think I wanted to second your comment, that I tend to look at these things as, I seek solutions, and I think that we all think of EDI as a solution.
Obviously, we are sitting here looking at a particular version issue, but you are pointing out that it is the sort of the feet of sand at this point, that even if we move to the new version without substantial changes, we are likely not to do much to help improve the industry. So, thank you.
MS. MILLER: The task group really felt very strongly that we bring forward there is potential benefit, and it was articulated very clearly, but there are still issues that we needed to bring forward, and they really recommended highly that they were highlighted during this testimony.
MR. REYNOLDS: And Lynne, we have kidded with you a lot, but the breadth of your experience, knowledge and the professionalism of your presentations is greatly appreciated by the committee. So, don't look past that.
MS. PICKET: Lisa, just one question. I notice in the written testimony that originally the time frame was supposed to be July for the completion of this survey, and then that wasn't doable and moved to August. Why such a short time frame? I wasn't clear on the constraints.
MS. MILLER: I am going to go like this, Stanley, would you like to answer that question.
MR.NACHIMSON: We had a lot of deliberations with the DSMO and a recognition of the fact that we needed to get cost benefit analysis.
The recommendation to move to the 004050 version was something that sort of came up fairly recently. What we wanted to do was tie it into a proposed rule that we had already begun work on, and we had certain deadlines for.
So, in order to get the impact analysis prepared in time to move the rule through our process, we had a deadline for getting that rule done.
So, to add in this additional stuff about adopting the 835 004050 version, we said, great, get it to us by X date so that we can stick it in this rule that is already going through the process.
MR. REYNOLDS: Did the result make you speed up or slow down?
MR. NACHIMSON: Neither one. We have plenty of other reasons to slow down. We put it in that rule, and it is still in that same package.
MR. REYNOLDS: All right, thank you very much to both of you. Do we have a copy of our proposed letter?
Agenda Item: Next Steps.
MR. REYNOLDS: Let's talk about, so what are our -- you know, we have had the day and a half of hearings on this. What do we want to do as our next steps. I am turning it over to Simon.
DR. COHN: I thought we had some very interesting testimony from the DSMOs, and obviously we have a report from them.
Obviously, it is the responsibility of the NCVHS to make recommendations to the secretary about changes and updates to the HIPAA standards.
Obviously, from my view the question is, do we do something with the current letter, do we need to do further investigation or hear more from the industry in terms of their views in terms of moving to a newer version of the 835 before we make a recommendation to the secretary.
I guess my general view would be that it might be useful to have us invite some others from the industry to comment on this before we make a final --
MR. REYNOLDS: I think that is a great point, especially since the people who submitted the findings stated that the response was not what they may have wanted it to be. It might be good, I think, if we at least hear that one more time. I think that would be good.
DR. COHN: Hopefully we can make a decision in a very timely fashion.
MR. REYNOLDS: So, we need to take a look at whether or not we want to have a piece at the February meeting, which we have already filled up and may not want to change. I will work with Donna on what exactly we decided for February.
MS. PICKETT: Just as a reminder, in the past the February meeting has always consisted of a report from the DSMOs. So, there is that issue of whether or not we would be continuing to do that, or have we heard enough with this.
MR. REYNOLDS: That is what we are saying. In February we need to hear more. Okay. So, let's move into the letter.
Agenda Item: Proposed Letter.
MR. REYNOLDS: What we would like to do today is come to an agreement, significant agreement, on the content of this letter.
What is going to happen is, the process will be that the full committee is being notified that, on the 19th of December, we will have a conference call.
We already had an executive committee conference call. We will have a conference call with the full committee to review this letter and pass it.
This letter will be sent out to the full committee next Wednesday, as the plan is right now. So, if we can come to significant agreement here today, then we won't need a conference call.
If we can't, then we will be chatting again as a group in the near future, being Monday or Tuesday, being the immediate near future.
I think let's plan to go through this and just -- Michael, if you wouldn't mind, just go ahead and walking us through it, kind of like we have done in the past with letters.
While we are waiting for Michael to get set up, let's read the first paragraph and make sure nobody has any issues with that before we get into the body. Paragraph one.
Let's move to background and discussion. Just leave it there, and as you fix it, we will look at it. Simon, should we read it?
DR. COHN: Why don't you read it. It is not that long of a letter.
MR. REYNOLDS: That is a good idea.
DR. FITZMAURICE: About a year ago, when we realized improvements to the NCPDP SCRIPT standards were possible, we asked NCPDP to keep us informed.
Specifically, we asked the National Council for -- I should move the first NCPDP up to the first NCPDP. Let me just make a note of that.
We asked NCPDP to report on progress as it was being made and, when completed, to show us the differences between the implementation guidance found in SCRIPT standard implementation guide version 5.0 (SCRIPT 5.0), and in the new SCRIPT standard implementation guide version 8.1 (SCRIPT 8.1).
On December 7, 2005, we learned that the rapid progress made by the industry working through the NCPDP has resulted in improvements to the standard we originally recommended for your adoption as a foundation standard, that is, SCRIPT 5.0.
A newer version, SCRIPT 8.1, was approved by NCPDP and the American National Standards Institute, and published in October 2005.
One of the changes found in SCRIPT 8.1 is an additional function of being able to transmit medication history information; other changes provide additional clarification for use of the standard.
We also learned that the industry generally has not implemented SCRIPT 5.0 and has actually implemented SCRIPT 8.1, to gain its benefits.
MR. REYNOLDS: Let's stop there. I have a comment, but Simon, go ahead.
DR. COHN: I would just probably change the last part where it says, has actually implemented, to is actually implementing.
DR. FITZMAURICE: Is actually implementing?
DR. COHN: Yes, I don't think it has been around long enough to -- maybe I am off on that one.
MR. REYNOLDS: Did you have another comment?
DR. WARREN: Take actually and move it in front of has. It should read, actually has implemented. You split your verb up.
DR. FITZMAURICE: And actually is implementing.
DR. WARREN: I thought we went back to it because it was implemented. What was the change?
DR. FITZMAURICE: The last line of the paragraph.
MR. REYNOLDS: If you could pull that up on your screen, that is helpful, so we could actually see what is going on.
DR. FITZMAURICE: And actually is implementing SCRIPT 8.1.
MR. REYNOLDS: My question becomes, you go to the beginning of the next-to-last sentence. One of the changes found in SCRIPT 8.1 is the additional function of being able to transmit medication history information. Is that not a foundation standard?
DR. COHN: No, that is not a foundation standard. That is a piece that we piloted.
MR. REYNOLDS: Also, this is a piece for which there is no other standard; is that correct?
DR. FITZMAURICE: Yes.
MR. REYNOLDS: Which also adds to the case of why 8.1 is even better. You see what it means?
DR. FITZMAURICE: It adds to the case being better, but we can't say that it is substantially a change for fear of the secretary saying --
MR. REYNOLDS: No, that is fine. I just wanted to make sure I understood. So, let's go to the next paragraph. Based on, let's start the next paragraph.
DR. FITZMAURICE: The second paragraph under background and discussion: Based on the information we received from NCPDP and input from industry representatives on December 7, 2005, NCVHS believes that the SCRIPT 8.1 standard is backward compatible with the foundation standard functions in SCRIPT 5.0, except -- and I will change that exception to except -- for the new function of transmitting medication history information found in 8.1.
This new function is not necessary for implementing the specified e prescribing transaction supported by SCRIPT 5.0, but it does add additional efficiencies of standardization. Further, SCRIPT 8.1 dispels confusion by providing more guidance than is found in SCRIPT 5.0.
MR. REYNOLDS: Comments?
DR. COHN: I mean, it is word smithing, but it still feels a little cludgy here. Maybe the first sentence is a little long, and I think what we are trying to say here, and I keep struggling, is that, you know, we are primarily concerned about the foundation piece, about those foundation standard functions being able to be used with 8.1, and, oh, yes, there are additional functions on the side here.
DR. FITZMAURICE: I am not dwelling on the additional functions, because what is relevant for the secretary is that it be backward compatible.
DR. COHN: Maybe instead of the comma, there needs to be a period.
DR. FITZMAURICE: Should there be sufficient additional functions, then it might have to go through the regulatory process.
DR. COHN: I think Judy and I are both sort of thinking that, before that except, there needs to be a period.
DR. FITZMAURICE: Should we just take out that phrase, except for the new function of transmitting medical history. Since that is not one of the foundation standard functions, maybe it --
MR. REYNOLDS: And it is not part of 5.0.
DR. HUFF: That was my suggestion. That is the part of it that concerned me, too, is that it is a contradiction there to say that, because -- well, the exception does not make it backward compatible. I would agree with striking that part.
DR. COHN: What I was going to say is that we need to somehow merge that with the next sentence, which might I think help. Basically, where we say something like the new function of transmitting medication history.
DR. WARREN: SCRIPT 8.1 has a new function.
DR. FITZMAURICE: Is not a foundation standard function.
MR. REYNOLDS: I don't know why we don't just put the period after SCRIPT 5.0, where we were, and starting with exception, get rid of the rest of the paragraph.
All I am recommending here is that it is backward compatible. We have already said in the previous thing what we think 8.1 brings to the table, and here we are saying that it is backward compatible.
The purpose of this whole paragraph is to remind the secretary that it is backward compatible and we are not hurting anybody.
DR. FITZMAURICE: The last sentence in that paragraph starts: Further, SCRIPT 8.1 dispels confusion. Would you want to put that sentence at the back of the previous paragraph so that it reads: We also learned that the industry generally has not implemented SCRIPT 5.0 and actually is implementing SCRIPT 8.1 to gain its benefit. SCRIPT 8.1 dispels confusion by providing more guidance than is found in 5.0.
DR. WARREN: If you go up in the previous paragraph, we have already said it provides additional clarification.
MR. REYNOLDS: I don't think that is necessary. I think that is a detail that is nota big deal.
DR. WARREN: I think we can get rid of the rest of that paragraph.
MR. REYNOLDS: That is getting down below where I think we might need to be. So, Simon, are you okay with the period after the SCRIPT 5.0?
DR. COHN: Yes.
DR. FITZMAURICE: So, we have a one sentence paragraph, which is fine.
DR. WARREN: I would put it up at the bottom of that first paragraph, or would that make it too long?
DR. COHN: I don't think it makes it. So, you are talking about getting rid of --
MR. REYNOLDS: Everything after exception.
DR. FITZMAURICE: That is not a bad one-sentence paragraph.
DR. COHN: Let me make a couple of changes to the sentence and you can say whether it is its own paragraph or the last sentence to the previous.
First of all, this says, based on the information received from NCPDP and input from industry representatives, I don't think it is NCVHS believes. I think NCVHS concludes that, first of all.
Basically, the it concludes that the SCRIPT is backward compatible, and it is not with the -- is it with the foundation standard functions or is it for the foundation standard functions?
DR. FITZMAURICE: For is good.
DR. COHN: Have we, up above -- I am trying to think if we somewhere really talked about the foundation functions in a way where this makes sense. Have we introduced the concept of foundation --
DR. FITZMAURICE: I think it is introduced for the first time in the middle of the first paragraph under background and discussion.
When we originally recommended it for your adoption as a foundation standard, SCRIPT 5.0. We could say: We originally recommended for your adoption SCRIPT 5.0 as the standard for foundation functions. That separates foundation and standards, and they go together. SCRIPT 5.0 as a foundation function standard?
DR. COHN: No.
MR. REYNOLDS: Could we say for the foundation standards in SCRIPT 5.0? We are bringing up functions and we never talked about functions before.
DR. COHN: I think what we are trying to differentiate here is that -- the problem is, I don't even think all of 5.0 is considered to be a foundation standard. Should we say, minus the status filled notification. Is that a correct statement?
DR. FITZMAURICE: Let's see how this looks. We can always change it back.
MR. REYNOLDS: What I was going to say, Simon, is backward compatible in functionality to SCRIPT 5.0.
DR. FITZMAURICE: So, we originally recommended SCRIPT 5.0 for your adoption for foundation standard functions.
DR. COHN: That is not quite true either, because we also recommended the 270, 271.
DR. FITZMAURICE: So, it is not complete, but it is ont inaccurate. We could put in we recommend all these other standards, too, but I didn't want to take away the focus of this SCRIPT being replaced by another SCRIPT standard.
DR. COHN: Okay, we learned that the rapid progress made by the industry work was an improvement.
DR. FITZMAURICE: Yes, that did make the sentence a little strange, didn't it. How is that, putting SCRIPT 5.0 in parentheses.
DR. WARREN: Do we need to do the same thing to the next SCRIPT 5.0? When you put the parentheses around SCRIPT 5.0, do we need to do the same thing right below it, around SCRIPT 8.1?
MS. GOVAN-JENKINS: I was going to suggest starting a new paragraph and add, based upon the information, to that. Start a new paragraph at, A newer version, and then add, you know, since that is only a one paragraph sentence.
DR. COHN: That paragraph has now been divided, which I think is good. Let's look still --
MR. REYNOLDS: I really like the one sentence paragraph. The reason that I do is that is a key message. That in itself is a key message.
DR. COHN: I am still messing with the last sentence of the background and discussion. What we really want to say is, resulting improvements to the standard we originally recommended -- SCRIPT 5.0 -- and you adopted as a foundation standard, as one of the foundation standards, as one of the e prescribing foundation standards.
DR. WARREN: Instead of for put as.
DR. COHN: I think, yes, you adopted as one of the e prescribing foundation standards, and get rid of functions at the end. Does that look good?
Now, let's look at the next paragraph here. Before we do that, let's look at the second sentence, because I think that this focus --
DR. FITZMAURICE: The only reason I put in the medication history was that someone could argue later on, well, here is a new function that wasn't even raised to the secretary's attention. I am saying, we are aware of it and, being aware of it, we then concluded.
MR. REYNOLDS: I still think it is good.
DR. HUFF: I was wondering if we could say it differently and say, this new standard included all of the foundation functions of 5.0 and has this function, rather than sort of calling this -- again, making an earlier distinction that it covers all the foundation functions but it has this other thing in it, too.
DR. FITZMAURICE: Say that again, Harry? I have lost it.
DR. HUFF: This newer version of the implementation guide -- the SCRIPT standard --
DR. FITZMAURICE: SCRIPT 5.0?
DR. HUFF: No, just say the SCRIPT standard, because you don't want to put 5.0 there, includes all of the functions of the foundation standard, and also includes the ability to -- just go down to transmit medication history.
DR. WARREN: Do we want to make any comment, this medication history was mandated in MMA and couldn't be done with 5.0, or just stay out of that?
DR. COHN: I think we want to stay out of that.
DR. REYNOLDS: I think it is true but irrelevant, or something like that.
DR. COHN: Get rid of the -- you don't need to redo the 8.1 again. It is in the sentence above. Includes all functions -- that is actually a very good paragraph.
DR. WARREN: The ability to transmit medication history information; other changes provide additional clarification. Somehow that doesn't make sentence.
DR. FITZMAURICE: Do you want that to be a separate sentence?
DR. WARREN: Maybe a period there, at information. Say, additionally, it provides --
DR. FITZMAURICE: We have got a lot of additions in here.
DR. WARREN: Get rid of the other addition.
MR. REYNOLDS: Further.
DR. WARREN: There you go.
MR. REYNOLDS: Furthermore, it provides other.
DR. COHN: It provides additional clarification.
DR. HUFF: At the risk of going backwards, in the first paragraph, I think we can eliminate most of that. I would say, you know, when we said about a year ago, I think we could jump right to, we asked the National Council for Prescription Drugs Program.
So, that whole part where it says, when we realized improvements were possible, we asked NCPDP to keep us informed, I think that is largely redundant with the fact that we asked them to report on their progress.
I think you could just go from saying, about a year ago, we asked the National Council for Prescription Drug Programs to report on progress, as it was being made.
We probably need to say something more there about progress and new version of the standard or something like that. It is just a thought. I mean, people, jump in if you don't like that.
DR. COHN: The question is, do we need, about a year ago. I think we have asked the National Council.
DR. FITZMAURICE: Yes, we could just do away with the whole thing there.
MS. PICKETT: Another thought here, while you may not want to say a year ago, you may want to be more specific.
In the first paragraph you talk about the recommendations in the two previous letters being September 2004 and March 2005.
Here we are saying something happened a year ago and we realized -- well, it wasn't realized, we heard testimony that work was already underway. Somehow you might want to kind of factor that in. It is not that you just realized it or it just kind of fell out. You actually heard testimony and you asked them to update you on those things that were underway. Lynn and I could not remember at what point we heard that testimony. We would have to go back and look.
DR. FITZMAURICE: I went back and probably it was December of 2004.
DR. HUFF: Were possible, or were in process.
MR. REYNOLDS: I would rather say in process, because where possible -- then we asked them to keep us informed, because they were in process. So, we said, keep us informed and then they went on.
DR. COHN: I would get rid of when and maybe put a period, about a year ago, we heard testimony about improvements to the standard were in process, period. We asked NCPDP to keep us informed of these changes.
DR. FITZMAURICE: We then asked NCPDP to keep us informed.
DR. COHN: We asked NCPDP to keep us apprised of these changes, or these improvements.
DR. WARREN: Let's not use changes. Let's use improvements.
DR. COHN: Improvements, yes.
DR. WARREN: We don't want him to focus on changes.
DR. COHN: Also, get rid of then. Let's look at the next sentence, then, because it sort of gets a little weird here.
DR. FITZMAURICE: This lays out what NCPDP told us yesterday, and also provides a definition.
MR. REYNOLDS: You were going to move NCPDP up.
DR. FITZMAURICE: Yes, I am going to move that up.
DR. HUFF: [Comments off microphone re: keep us informed].
DR. COHN: That would actually be a little bit easier. Then get rid of the entire next sentence.
DR. FITZMAURICE: That defines what SCRIPT 5.0 is and SCRIPT 8.1 is.
DR. HUFF: So, you could pick up the differences, or you could say, report back to us about the differences -- [comment off microphone].
DR. FITZMAURICE: So, specifically, we asked NCPDP to report, or to show us the differences? I am not sure how to fix that.
DR. HUFF: How about this. We asked NCPDP to keep us informed of these improvements, and report back on differences.
DR. FITZMAURICE: Report back on differences in what, between 5.0 and 8.1?
DR. HUFF: Between the old and the new versions.
DR. COHN: Actually, maybe the solution here is, rather than report back when they were completed, keep us informed of these improvements and report back as progress was being made. That allows the next sentence to exist, as well as the next one.
DR. FITZMAURICE: But we have duplicated what we say in the next sentence.
MR. REYNOLDS: When you say that part, make sure you are clear what we are talking about.
DR. HUFF: I think we could just say, we asked NCPDP to show us differences between -- [off microphone].
DR. FITZMAURICE: Okay, but we also specifically asked them to report on progress. Now, we don't say anything about completed. We want to emphasize to the secretary that the work is completed.
DR. COHN: That is the next sentence.
DR. WARREN: I think that is where we could say, on December 7th we learned that --
DR. COHN: Yes, that is what the next sentence is.
DR. WARREN: Put there that we learned --
DR. COHN: That is already there.
DR. WARREN: But we have got rapid progress there. Are they done?
DR. FITZMAURICE: Resulted in completed improvement.
MR. REYNOLDS: Are we ready to move?
DR. COHN: And I think we will pass this, and give the chair the ability to do additional word smithing as needed.
MR. REYNOLDS: Okay, we have got to go to the preamble?
DR. FITZMAURICE: Where do you want to go from here?
DR. COHN: Preamble, the next paragraph.
DR. FITZMAURICE: This may seem a little stilted, but that is quoted out of the Federal Register.
DR. WARREN: Do we want to say, the industry has held back from implementing the improvements represented in 8.1 or just leave it straight the way it is.
MR. REYNOLDS: I am sure we could say, the currently accepted standard. Isn't that what it is, your currently accepted standard, 8.1? Their currently accepted standard?
DR. WARREN: I think the reason this was brought to us is that there is some significant advantage in 8.1 over 5.0 because of medication history and the guidance.
DR. FITZMAURICE: SCRIPT 8.1, that refers to the guidance.
DR. WARREN: What I was trying to get at is, just one more time, expressing the fact that the reason that the industry has held back -- that there are improvements in 8.1 that industry needs to implement, and they won't be able to unless he waives this.
DR. FITZMAURICE: So, we talk about gaining the benefits up here. Do we want to say, from implementing 8.1 to gain the benefits? It seems to be duplicative, but I get your point that we don't want to not remind the secretary that there are benefits to 8.1.
MR. REYNOLDS: I think we could add that some place in the recommendations. This is all a preamble. Let's go to recommendations to see if we can't really hit that hard.
DR. COHN: Could I just do some quick word smithing. Aren't we saying that the industry is held back from implementing 8.1 for e prescribing.
MR. REYNOLDS: Okay, let's go to the recommendations. Go ahead and read them.
DR. FITZMAURICE: Believing the testimony to be credible and accurate, that SCRIPT 8.1 does not incorporate significant changes from SCRIPT 5.0, and is backward compatible with the foundation standard functions in SCRIPT 5.0, NCVHS recommends the Secretary adopt the new version SCRIPT 8.1, as well as the previously adopted version, 5.0, for meeting the e prescribing transaction standard functions.
This means that compliance with either version 5.0 or 8.1 would constitute compliance with the e prescribing standard under MMA.
The industry would neither be compelled nor prohibited from implementing SCRIPT 8.1. Let's see if I have defined MMA above. Yes.
MR. REYNOLDS: Would it be that it constitutes initial compliance?
DR. FITZMAURICE: There is nothing in the regulation about initial compliance.
MR. REYNOLDS: All right, recommendation two.
DR. HUFF: [Comments off microphone.]
DR. FITZMAURICE: It shows the basis for what we express as our belief.
MR. REYNOLDS: If they lift the recommendation just by itself, it tells the story. Stan, I would agree with you in a normal letter, but if somebody just went straight to the recommendations, it retells a little bit of the story.
DR. COHN: I am not going to spend time on word smithing this, but I think we probably need to say something a little different than believing the testimony to be credible and accurate. Say, sort of based on testimony and information received from the industry -- received from the industry that -- then go with, that SCRIPT 8.1 does not incorporate significant changes.
DR. FITZMAURICE: Say that again, because I am leading into the recommendation.
DR. COHN: I am just saying get rid of -- based on testimony and information received from the industry, that SCRIPT 8.1. Basically get rid of -- no, you have got it all down below. I am having you remove a bunch of stuff here. There we go. I think that is all fine.
MR. REYNOLDS: Is that a period after SCRIPT 5.0, the second one in the third line?
DR. FITZMAURICE: That is a comma.
MR. REYNOLDS: That is a long sentence.
DR. COHN: That's life.
MR. REYNOLDS: Okay, moving right along, let's take a look at recommendation two.
DR. FITZMAURICE: Recommendation two. Because time is of the essence for permitting the industry to implement SCRIPT 8.1, NCVHS also recommends the Secretary waive notice and comment rule making under an administrative procedure act exception for the adoption of SCRIPT 8.1 as a foundation standard, so that it may be implemented as rapidly as is feasible for the identified foundation standard functions.
NCVHS is pleased to support the process by which the Department of Health and Human Services can improve the efficiency and effectiveness of e prescribing.
Here we are saying, do it fast. Do one, but do it fast. The Secretary would have two decisions to make. One is that version 8.1 is compatible with version 5.0, and so either can be adopted.
Secondly, the Secretary is being recommended by NCVHS to do it fast, to make an exception to the notice of proposed rule making, comment period, final rule.
MR. REYNOLDS: Or we could go up here, where NCVHS recommends the Secretary adopt the new version SCRIPT 8.1 as -- in other words, adopt it prior to January 1.
DR. FITZMAURICE: I am not sure the Secretary can move that fast, because CMS has now got to prepare something for the Secretary's signature to make this happen.
MR. REYNOLDS: Does anybody have a problem with the second recommendation?
DR. COHN: No, I just had a little bit of word smithing. When you say, for the adoption of SCRIPT 8.1, for the identified foundation standard functions.
DR. FITZMAURICE: But we haven't identified them anywhere.
DR. COHN: Maybe it is for the foundation standard functions.
DR. FITZMAURICE: Okay, good.
DR. COHN: Get rid of the rest of the sentence. No, so that it may be implemented as quickly as is feasible, period. So, keep going and put a paragraph after feasible. Now get rid of the rest of it.
MR. REYNOLDS: Simon, I know you have got to go to a call. What I would like to do is entertain a motion to accept the letter.
DR. COHN: I guess I would also give the co-chairs the ability to make minor word smithing modifications to improve readability.
[Motion made and seconded.]
MR. REYNOLDS: In favor?
[Voices heard in favor.]
MR. REYNOLDS: Opposed?
[No voices heard in opposition.]
MR. REYNOLDS: What I will also do is, Michael, if you will e mail this to the committee --
DR. FITZMAURICE: To the subcommittee.
MR. REYNOLDS: To the subcommittee. We have to have this to Marjorie by the end of the day Tuesday. I would like each of you, if you have any further word smithing, that you let me know by the end of the day Monday. Otherwise, we will consider it moving forward.
DR. FITZMAURICE: I don't have e mail addresses for all the committee.
MR. REYNOLDS: No, just us.
DR. FITZMAURICE: To the same people I send it last night?
MR. REYNOLDS: Right, which is this subcommittee. Thank you, everyone.
[Whereupon, at 2:05 p.m., the subcommittee meeting was adjourned.]