Hubert H. Humphrey Building
Room 505A
200 Independence Avenue, SW
Washington, D.C.
DR. COHN: Welcome, everyone. We will get started. Good morning. I want to call this meeting to order. This is the first day of three days of hearings of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics. The committee is the main advisory committee to the U.S. Health and Human Services on national health information policy.
I am Simon Cohn, Chairman of the Subcommittee, and the National Director for Health Information Policy for Kaiser Permanente. I want to welcome subcommittee members, staff and others here in person. I do want to mention that normally, we are on the Internet. My understanding is that the connection with the DA who hosts us for these sessions is still being established, and we will let everyone know when we actually are on the Internet.
Obviously there is a lot to cover over the next three days. Today we continue our work regarding e-prescribing standards As all of you know, the Medicare Modernization Act calls on the Secretary to adopt standards for e-prescribing, and the NCVHS has been directed to develop such standards recommendations.
We start the day with presentations and discussions with e-prescribing networks. Thank you for being here. After the break, we are fortunate to have a presentation from Doug Bell from Rand on the recently completed study on e-prescribing. After lunch we have David Bates coming in to talk about patient safety as it relates to e-prescribing. Then after the afternoon break, we have implementers who will show their thoughts on other e-prescribing standards and issues.
Finally, somewhere between five and six, we will finish with the testimony, have open mike, and then have subcommittee discussions. So clearly, we have a full day.
As mentioned, the hearings will continue all day tomorrow, and then on Thursday they will continue in the morning and then adjourn around 1 p.m. I want to thank Jeff Blair, our vice chair, for his leadership in moving forward with the e-prescribing work plan, and Maria Friedman, our lead staff, for her valued and tremendous efforts putting these hearings together.
I want to emphasize to all that this is an open session. Those in attendance are welcome to make brief remarks, as long as their comments are germane to the topics at hand. We will also have time at the end of the afternoon for brief comments during the open microphone session for those in attendance. Finally, when the Internet is up and running, we welcome generally e-mails and other communications in writing from those in attendance or in the Internet.
With that, let's have introductions around the table and then around the room. For those on the National Committee, I would ask, if you have any conflict of interest related to any issues coming before us today, would you please so publicly indicate during your introduction. Maria, maybe you would like to start the introductions.
MS. FRIEDMAN: Thank you, Simon. I am Maria Friedman from the Center for Medicaid and Medicare Services, and lead staff to the subcommittee.
DR. WARREN: I am Judy Warren, a member of the subcommittee, and work at the University of Kansas.
MR. REYNOLDS: I am Harry Reynolds, vice president of Blue Cross Blue Shield of North Carolina and a member of the subcommittee.
MS. TRUDEL: Karen Trudel, Center for Medicaid and Medicare Services, staff to the subcommittee.
MS. PICKETT: Donna Pickett, National Committee on Vital and Health Statistics, Centers for Disease Control and Prevention and staff to the subcommittee.
DR. SCANLON: I am Jim Scanlon, HHS Office of Planning and Evaluation, and I am the executive director of the full committee.
DR. GUINAN: Jack Guinan, CTO, ProxyMed.
MR. BRADLEY: CEO, RxHub.
MR. HUTCHINSON: Kevin Hutchinson, CEO, SureScripts.
DR. WHITTEMORE: Ken Whittemore, Vice President of Professional and Regulatory Affairs for SureScripts.
MS. AMATAYAKUL: Margaret Amatayakul of Margaret A Consulting. I am assisting the subcommittee.
DR. HUFF: Stan Huff with Intermountain Health Care and University of Utah in Salt Lake City, a member of the subcommittee. I don't know that I have any conflicts for the things that are going to be discussed today.
DR. STEINDEL: Steve Steindel, Centers for Disease Control and Prevention, staff to the subcommittee and liaison to the full committee.
MR. BLAIR: Jeff Blair, vice president of the Medical Records Institute, vice chair of the Subcommittee on Standards and Security. I'm not aware of any conflicts of interest related to the topic that you are describing.
MS. SQUIRE: Marietta Square, HHS, CDC and staff to the subcommittee.
MR. MANTOOTH: Mark Mantooth, Health and Human Services Office of General Counsel.
MS. HOWARD: Cynthia Howard, CMS.
MS. GILBERTSON: Lynn Gilbertson, National Council for Prescription Drug Programs.
MS. CANFIELD: Ann Canfield, RX Benefits Coalition.
MS. THOMAS: Ceil Thomas, The Pink Sheet.
MS. PARKER: Wendy Parker, Camarick.
MR. BOSCOWITZ: Roy Boscowitz, National Association of Chain Drugstores.
(Whereupon, the remaining introductions were performed off mike.)
DR. COHN: Thank you all for joining us. Jeff, before we start our session, would you like to make a few introductory comments?
MR. BLAIR: Sure. Thank you, everyone, for being here. I am going to just say a few background remarks.
I am assuming all of you are aware of the fact that this initiative is being driven by the requirements in the Medicare Prescription Drug Improvement and Modernization Act. In that act, it wound up requesting that the NCVHS explore the areas of standards for e-prescribing. The law was especially specifically in terms of the areas of standardization that we should consider and the number of stakeholders, or not the number, but the specific names of the stakeholders that we should listen to. l thought the list was long, there were some additional stakeholders that we felt were important, that we have also added to that list. Many of them are here today and tomorrow for us to hear from.
For those of you who are looking for a little bit of a perspective on how the NCVHS is approaching this task, there is a working document. It is a work plan. It is version eight right now. Most of you -- I don't know if I can say most of you; many of you obviously have gotten copies of that work plan, but if there is anyone who hasn't, please ask either Maria Friedman or myself or Marietta Squire, and we will be more than happy to get you a copy of it. That is a work in progress. It will be changed and updated, but at least it will give you some feeling for the directives and where we are going forward.
Now, in addition to the oral testimony today, the NCVHS has asked all of the testifiers to respond with written testimony as well. There is a lot of important information in the written testimony which, to be honest with you, is too detailed to wind up using that guidance for the testimony as guidance for oral testimony, but there is important information in there, and I think many of you would be interested in that. So again, either Marietta Squire or Maria or myself, let us know and we will get you copies of that.
Other than that, I think you all have seen the agenda, so I am not going to repeat the agenda. I am just going to say welcome, and I am looking forward to hearing from all of our testifiers today.
DR. COHN: I do want to announce that we are now on the Internet. For those on the Internet, we have gone through introductions. This is the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics, and we will be starting our first session on e-prescribing networks.
With that, Kevin, do you want to lead off?
MR. HUTCHINSON: Good morning. As I mentioned, my name is Kevin Hutchinson. I am the president and chief executive officer of SureScripts. Accompanying me is two of my SureScripts colleagues, Bob Beckley and Ken Whittemore. Speaking for our entire organization, I thank the committee for inviting us here to share our experiences and conclusions, gleaned from an ongoing effort to deploy electronic prescribing nationwide.
SureScripts was created by the National Community Pharmacists Association and the National Association of Chain Drugstores in 2001 to improve the overall prescribing process. Working with the nation's premier health care technology vendors, SureScripts is creating an open, neutral and secure system that is compatible with all major physician and pharmacy software systems.
More than 60 percent of the nation's retail pharmacies have now tested and certified their pharmacy application on the SureScripts network. That number is expected to grow to more than 75 percent of the pharmacies in the U.S. by the end of the summer, 2004.
In the fourth quarter of last year, SureScripts launched a national rollout of electronic prescribing in pharmacies all across the country, and are in various stages of activating those stores for e-prescribing connectivity, now that the majority of the pharmacy software certification and testing is complete.
Since the beginning of 2004, in coordination with the pharmacies, we have activated electronic prescribing in eight states, with more than two dozen states currently scheduled with go live dates before the end of 2004. Additional markets will continue to go live in 2005 and through 2006. We are out of the planning stage and into the execution phase for electronic prescribing connectivity.
As I just mentioned, SureScripts was created to improve the overall prescribing process. This is an important point that I would like to touch on for just a moment. We found that all too often, the popular but narrowly focused term, e-prescribing, has caused confusion and misunderstandings about the true scope of what we hope to accomplish for patients and the health professionals who care for them. The prescribing process does not begin when the physician first touches the prescription pad, nor does the process end when the pharmacist ends the medication to the patient.
Looking at the prescribing process from the standpoint of the physician, one can see there are numerous steps that occur before the creation of the prescription. The patient's chart is pulled and reviewed, the patient is interviewed and examined, a diagnosis is decided upon, and a course of therapy is contemplated and then decided upon. If it is decided that medication therapy is an appropriate choice for the patient, it is at that point that a prescription is created, and also noted in the patient's chart. When it comes time to authorize a refill renewal request for the patient, many of these activities are repeated. All in all, considerable time, expertise and judgment are invested in these activities. We believe there are several points in the process that might be improved beyond the simple act of generating a prescription.
At the pharmacy end, much more is involved than generating a prescription medication than simply placing tablets or capsules in a vial. Electronic pharmacy patient records, which include allergies, existing medical conditions must first be created. Prescription insurance information must also be inputted and updated periodically. Upon the receipt of a prescription for a patient, prescription infrastructure is inputted in the pharmacy computer, which immediately performs a drug utilization review against the medications listed in the pharmacy record. Once the pharmacist has reviewed any DUR issues flagged by the pharmacy system, the prescription is billed to the insurer. During the billing to the insurer, an additional DUR check is performed by the insurer, and the resultant payor issues, either financial, claim or clinically related, are resolved by the pharmacist and the prescription is prepared for dispensing. The process is then concluded when the prescription is dispensed to the patient, and the patient is counselled on its use by the pharmacist.
My point in going into all of this detail is to emphasize to the subcommittee that our goal must be to improve the overall prescribing process. To focus too narrowly on the act of generating a prescription and transmitting it to a pharmacy would ignore many opportunities to enhance the level of safety and quality of health care delivery to Medicare patients. It would be our pleasure to assist the subcommittee in working toward this goal.
I would now like to address the specific questions about standards for prescribing that were proposed to us by the subcommittee.
You first asked what are the best standards for code sets to meet the requirements of the MMA, which do we use, what are their strengths and weaknesses, and is their nationwide adoption necessary.
MR. BECKLEY: In implementing our electronic prescribing connectivity system, we selected the nationally recognized NDPDP script standard to serve as the foundation of our transaction engine software. The NCPDP script standard was developed to facilitate the electronic bidirectional transmission of prescription information between prescribers and pharmacies.
It is our experience that the use of the script standard improves patient safety, quality of care and efficiency, without presenting any undue administrative burden on prescribers and pharmacies. We believe that the NCPDP script standard is the best standard to meet the e-prescribing needs of Medicare patients and physicians and pharmacists who serve them.
The script standard was developed through a consensus process among community pharmacies, community pharmacy organizations, pharmacy software vendors, database providers and other stakeholders. Further, the standard addresses the electronic transmission of new prescriptions, prescription leaflet requests, prescription fill status notifications and cancellation notifications, the nuts and bolts of e-prescribing.
Further enhancements could address other possibilities that may include patient eligibility, compliance, lab values, diagnosis, disease management protocols, patient drug therapy profiles and/or prescription transfers.
The strengths of the NCPDP script standard are that it is a national standard that addresses the vast majority of the core functionality required in the MMA. It currently facilitates the bidirectional transmissions of prescription information between prescribers, dispensing pharmacies and pharmacists, and holds the potential to allow for the transmittal of information eligibility and benefits and medication history.
A weakness of the script standard is that it is not widely used in the inpatient and long term care settings. However, to address the weakness, NCPDP and HL-7 are initiating a collaborative effort to harmonize the two standards with respect to e-prescribing.
In terms of the best code sets, we found that the NCPDP provider identification number, which many pharmacies adopted several decades ago and is used universally in the processing and payment of prescription drug claims works extremely well as the pharmacy identifier code set for e-prescribing. It was formerly known as the NABP number.
The strength of the NCPDP provider identifier is that it is used nationally to identify the participating community pharmacy. This unique identifier is used by boards of pharmacy, payors and telecommunications switches to precisely identify pharmacies for a variety of purposes. This identifier has been used effectively by the stakeholders for several decades and has been refined substantially over that time. We do not believe that it has any weaknesses.
MR. HUTCHINSON: With respect to packaged drug code sets, we believe that NCVHS should consider the NDC number as the best standard. The NDC number has also been used for several decades, both for prescription drug claims processing and to facilitate internal data processing needs in community pharmacy computers. SureScripts transmits the NCD number when submitted by either prescriber or pharmacy software.
The strength of the NCD number is its universal acceptance as a packaged drug code set and its use by payors, including CMS, pharmacies, manufacturers and database companies. The primary weakness of the NDC number is that it does not specify component ingredients in a drug product, and thus is not useful as a drug ingredient code set. Even when an NDC number is used in combination with proprietary drug ingredient databases to meet this need, there are problems, because there are no standardized references between such databases.
All three of these standard code sets, the NCPDP script standard, the NCPDP provider identifier for pharmacies, and the NCD number as the packaged drug code set, are recognized and adopted nationwide.
The subcommittee also asked if there if there are any e-prescribing standard or code set gaps and what barriers might prevent their development and adoption.
The first e-prescribing code set that SureScripts encountered was that of a prescriber identifier code set. Code sets that have been suggested as useful for this purpose include the prescriber's DEA number, NCPDP's HC ID and the MPI, all of which have significant deficiencies.
Because there is not a patient identifier code set that uniquely and adequately identifies prescribers on a national basis, SureScripts was compelled to create its own SureScripts prescriber ID or SPI for internal use. The SPI consists of an SPI route and a location ID. Because a physician can prescribe for more than one location, the location ID is used to distinguish between multiple locations for the same provider.
This is important, because the proper mounting of refill renewal requests and prescription fill messages is not possible without location information. It is in this way that SureScripts has been able to overcome the location deficiency of the NPI.
Another e-prescribing code set gap is a nationally accepted non-proprietary prescription direction, or SIG database. Because of this, SureScripts must now transmit prescription directions in free text format, which compromises a portion of the efficiencies that pharmacy providers had hoped to achieve when implementing e-prescribing.
The lack of a standard patient identifier is also a gap in code sets when it comes to e-prescribing. It is unlikely that either medication or medical histories will be implementable without a nationally accepted standard patient identifier code set. Current methods of trying to identify a patient are done through complex algorithms which add to deployment costs and vary in accuracy. Either a standard nationwide patient identification system needs to be established or a master index needs to be maintained.
As to drug ingredient code sets, there needs to be a cross reference between proprietary drug ingredient databases, as the NCD number was not created to list individual ingredients.
Finally, the subcommittee asked, what incentives or other suggestions should the government consider to accelerate the development and/or adoption of e-prescribing standards or code sets. As the subcommittee is aware, the MMA recognizes the financial challenges that e-prescribing will likely represent for prescribers by providing a grant program that will provide a 50 percent financial match toward the purchase, lease or installation of computer software and hardware, upgrades or other improvements to existing software, and providing education and training to prescriber staff on the use of e-prescribing technologies.
The widespread implementation and use of the developed e-prescribing standards and code sets could be further accelerated by expanding the grant program to pharmacies, which are supporting a disproportionate share of the overall e-prescribing infrastructure and transaction costs.
Further, we recommend that the 2006 pilots be used to assure that the new standards mentioned in the MMA do not impose an undue administrative burden on health care professionals involved in e-prescribing.
It is imperative that these standard code sets be proven to work in the private sector prior to requiring their national use. Again, to further accelerate the adoption and use of e-prescribing standards and code sets, SureScripts recommends that the financial provisions of the MMA be expanded to include pharmacies.
MR. BECKLEY: In closing, I bring up what we believe to be one of the most critical aspects of insuring widespread adoption and integrity in the electronic prescribing process. As I mentioned in the opening, SureScripts was established in the pharmacy industry to insure an open and neutral secure system for the widespread adoption of electronic prescribing. In fulfilling that mission, SureScripts has created certification rules or standards that preclude any technology partner connected to the SureScripts network from displaying commercial messages with the intent to influence a physician's decision in medication therapy or with the intent to influence or alter a patient's choice of pharmacy, be that a chain pharmacy, an independent pharmacy, a supermarket pharmacy, mass merchandiser pharmacy or mail order pharmacy. However, of course, we believe in and our rules support the use of, formulary management at both the point of care at the pharmacy and the point of care with the physicians.
This approach is not dissimilar to the approach of the banking industry as taken with the deployment of electronic banking across the country, for the banking industry has established standards and rules to be used when interacting with banks electronically. Whether you are paying bills online, electronically depositing salary checks or withdrawing cash from an ATM, banks do not compete to win your business or influence how much cash you take out, unless of course you are taking out more than you actually have, which they will kindly give you a polite message.
The point is that MMA does address the point that electronic prescribing should not in fact allow messages unless, and I quote, it relates to the appropriate prescribing of drugs, including quality assessment measures and systems referred to in Subsection C1B. I believe this to be the committee's largest challenge in defining what is an appropriate formulary or clinical alert message in what is disguised as a commercial message.
In the past year and a half since I have been at SureScripts, I have personally witnessed some very interesting business models by companies, where the belief that large sums of money can be made is a message appropriately or inappropriately, physicians with the intent of switching medication therapies or a patient's choice of pharmacy.
I'm sure the banking industry realized early on the value of the consumer eyeballs on their ATMs, online checking and personal banking software connected to their banking networks, and elected to err on the side of protecting the integrity of the electronic process and maintain consumer confidence in the system. A high level of automation existed in the banking industry prior to the deployment of electronic banking. The challenge was to get consumers and companies to connect to them electronically to improve the efficiency and the security of the banking process. Processes were created to leverage the existing technology by extending the process out to the consumer.
This is very similar to the opportunity before us today in the health industry. A high level of automation exists in pharmacies today. Close to 100 percent of pharmacies have automated their clinical and financial claims process. As an industry, we are exploring the possibilities to leverage not only the existing technology, but also build upon the relationship that exists today between a patient's pharmacist and a patient's physician, to enable the two health professionals involved in the process to make a safer, more efficient and potentially higher quality medication decision for us all as patients.
We at SureScripts thank the subcommittee for the opportunity to share our experiences and findings with respect to standards currently used in the United States to facilitate the adoption of bidirectional electronic prescribing communications between prescribers and pharmacies. We encourage NCVHS to support current e-prescribing efforts that have evolved using these standards, and build on ones that need further clarification and/or description.
Thank you for your kind attention.
DR. COHN: Thank you very much. Jim Bradley, I believe you are next.
MR. BRADLEY: Jack has agreed to run the slide show here for me this morning.
First to the subcommittee, thank you very much for allowing RxHub to be allowed to participate. Before I start my remarks, I think it is important that one's perspective be put into a context. I was employee number one at RxHub, but that was after a number of years, in which I would characterize most of my backgrounds being one of a payor.
In addition to that, I am old enough here over the many people in the room, and so I am old enough to remember the days when there was no drug benefit in a lot of the commercial insurance programs, and I got to watch what happened as we started the provider drug benefit, and looked at such issues as adverse selection, one of open access to a benefit that didn't exist before. I went from there into a belief that we were going to have to actively engage the physician and patient as we ran the health care system moving forward, because without that, we had a lot of inefficiencies.
I also got to watch what happened when first there was a catastrophic drug benefit that incented automation. Then there was an incenting by HHS for an electronic claims submission for Medicare claims. I got to see what happened to us in the commercial sector, meaning game over. It accelerated the process in such a way that we commercially were able to avail ourselves of high degrees of electronic submission for commercial claims.
As we started the job at RxHub, we felt there would be several bellwether events, if we were to achieve the dream of having an informed patient and physician making rational economic and clinical decisions at the point of care. One of the bellwether events was that the physicians had to adopt technology. That was going to require a healthy technology sector.
At the time, and this was 2001, you will recall that we had a dot-com bubble that had burst, a lot of early adopters who had been burned, and a lot of cynicism. So we felt that until some of these firms re-entered the marketplace, we had no hope for automation.
The second bellwether event, we felt, was going to be some form of drug benefit passing for our senior citizens. The reason for that is that in most physician practices, as you go in and try to change the way they work, what you find is, you can only represent about half the prescription buy-in in that clinic. So most tools that need to get adopted wouldn't represent enough of the physicians' business to make that kind of change.
So last year with the passage of the Medicare benefit, we felt, now we are in a new world. It is uncharted. It is an unprecedented benefit.
As I go through the slides now, I want you to remember that perspective. Our perspective at RxHub has been as much around the affordability of a benefit, as much as just the electronic automation of it, and making sure that the information was available in the physician office to allow for that kind of informed decision making.
I won't repeat a lot of what Kevin said. I think a lot of the early work with e-prescribing took a very simplistic approach. The simplistic approach was, how do you get a prescription from a physician office to the retail pharmacy where it is dispensed. The problem with that approach is, if there is anything flawed with today's process, it just automates the flaws. So we felt that it was very important to dissect the work flow process in a physician office, and we broke the process down into these four areas. There is a part we call prescribing. That is the decision support effort on the front end of a prescription that helps the physician and patient come to a conclusion as to what is appropriate therapy.
The second is the actual writing of the order. The writing of that order needs to be done in such a way that it takes advantage of that information that is on the front end. There is the delivery of that to the patient, then finally, somehow it gets to where the prescription is going to be dispensed.
Now, just to be clear and go on the record about this, we fundamentally believe at RxHub in patient choice. The patient should be able to choose the drug therapy, they should be able to choose where that gets dispensed. However, in a rational system that provides this level of coverage, those choices are going to have certain costs and tradeoffs. We believe in an informed choice to be made at that point of prescription and fulfillment.
So as we go through the definitions of e-prescribing, we say that it has a number of things. Access to clinical decision support. We believe that sharing of the patient history is important to the clinical decision making process. We think that we need to increase the practice efficiency of physicians in both the inpatient and outpatient settings, and also in providing an efficient business framework. So this is really an information problem more than anything else that we are trying to solve here.
In the Medicare legislation, there are a number of provisions that I'm sure everyone in this room is familiar with, but in case you are not, it starts with a process of determining eligibility for the drug benefit. So the first piece of information that is required is something about eligibility, what that benefit looks like, including formulary and preferred drug and tiered benefit structures and so forth need to be understood.
There needs to be clinical information on the drug being prescribed, and information about the availability of lower cost therapeutically appropriate alternatives, meaning that the data has to be rich enough to provide that patient and physician with a rational set of choices.
Absent this information, this benefit has the opportunity to bankrupt Medicare. In other words, I watched what it did in the commercial sector. Without some form of structured approach to the benefit and the decision making, we have a financially unviable benefit here.
So what do we need? Part of the problem we have today is that we have a general lacking of an infrastructure to provide this kind of information. I think that we start with the first level problem being patient identification. Again, by matter of perspective, some of you and I worked together back in the early '90s in WIDI after Secretary Solomon initiated that work effort with a number of industry colleagues; we were trying to address the administration simplification process.
Back in 1992, we talked about the need for a patient identifier that could easily and uniquely get you to the right individual for the storage of both personal and clinical and other kinds of information. I think it in 2004, we are still not there. So if we wait another 12 years without being able to identify the patient, we are going to have a real problem. We are fairly cynical about the ability to get this done in any kind of near term time frame, particularly as this benefit rolls out.
The second thing is, I think you have to talk about an enrolled population. What we are talking about when we say enrolling a population, we just passed a drug benefit that should allow us to enroll seniors now into organized programs, and that enrollment process is the way one organizes for this patient identification process.
Once you have patients in an enrolled database, you can make connections to everywhere else. Absent that enrollment process and that directory process that gets you to the patient, most efforts to consolidate information, interoperability and other things, the systems break out. If you can't identify the patient and then figure out where the data is, you cannot organize an infrastructure that is feasible.
Here is how we approached at RxHub the patient identification process. Remember, as we started RxHub in 2001, at the point in time we did not have a drug benefit. I was not personally given the latitude to wait for a unique patient identifier for all citizens. I had to get going.
So how do we approach the problem? In the three PPMs that founded RxHub, we had approximately 150 million lives. So what we did is, we ran those 150 million lives through statistical algorithms to identify those data elements which could uniquely get us to the patient and have no false positives. In other words, if we found Jeff Blair's evil twin and delivered a medication history, we had a problem. We had to find the right Jeff Blair.
At times in the world of HIPAA, you might like to present the potpourri of alternative Jeff Blairs to the physician and let them select one. You cannot do that. So there are times when we say we cannot find the patient when we really have them in our database, but that is just part of the problem here that we have to put up with.
We know after millions of transactions through this MPI, we know of no false positives, meaning we have asked physicians who are looking on the other end to verify that we have the right patient, and we know of no instances of a false positive.
So 150 million lives, five elements that you can get off their driver's license, no false positives, and we can identify those people in less than a quarter of a second. We think it is no issue for a Medicare benefit to be built around a commonsense approach like this one to identify seniors who are in this program.
Another thing about this MPI is, it immediately tells us about coordination of benefit opportunities. For those of you who aren't from commercial insurance backgrounds, COB is nearly impossible for drugs because of the high volumes and the low returns of the COB effort. This allows us to immediately identify those multiple coverages and adjudicate them.
The final point. We do not store patient information. We do not store anything other than these five data elements and a unique identifier at RxHub. So we don't have to worry about competing companies sharing their customer master files. That is a big hurdle to get over. We just store enough elements to identify the patient, and then point at where the drug coverage is.
For eligibility, coming at that problem, we brought a payor's perspective to it. WIDI a long time ago recommended the ANSI standard set for eligibility. Therefore, most systems that operate in physicians' offices today understand the ANSI transaction set happens to be the X-12 70 and 71 transaction. That is the one that RxHub suggests for the eligibility process in the physician's office. It is simpler to adopt a variant of that for drug benefit eligibility than to invent a new transaction.
It also is the one suggested by HIPAA for eligibility. There are other transactions, some of which come from NCPDP. A number of NCPDP transactions we will talk about here, but for this one, it is not widely used for eligibility by physicians, and we think it is harder to adopt than ANSI X-12. So it is nothing against the NCPDP transaction; it is primarily tailored to pharmacies. Most physicians' offices do not have the capability.
Medication history. This was something that has emerged over the last year. Actually, our work with medication history started before RxHub existed. At a startup I did, we worked with Medco at the highest volume prescribing site, and found that after automating the physician office, the number one thing that the physicians found helpful to their practice was the medication history that could be delivered.
This medication history when it comes out of a payor database basically has all of the prescriptions that are being paid for, regardless of the site of dispensing, regardless of who prescribed them. At RxHub today, these transactions are alive and well. We can deliver a medication history always less than ten seconds, most of the time less than five seconds.
The medication history, we believe, is number one sticking point for physicians. In other words, you can automate a physician office to improve their efficiency. You also need to improve the quality of care that is being delivered. Physicians resonate to this history, and we think it is important.
No standard for medication history existed, so RxHub developed one. We are in the process. We used as much of the NCPDP transaction set as we could to deliver this, and we are in the process of taking that standard through the NCPDP process. We do believe that the nationwide adoption of medication history transactions is required for the patient safety objectives that come out of this bill as well as other bills and other commercial efforts such as Leapfrog and so forth.
In terms of how you get to the medication history, I think after we developed the transaction and put it in production, a lot of people said this is a great idea. We have got medication histories too, and we will all compete with each other to deliver medication history.
The problem with medication history though and doing it feasibly, you have to deliver it in seconds, not minutes, not hours and so forth, and you have to very quickly and reliably find the information.
What I would suggest is that once the senior population is enrolled and alongside the commercial population, the payor database that has the paid information about prescriptions that are delivered is the most complete to start the medication history, meaning, in that case you have all prescriptions that have been paid for. The ones you would not have are those that are paid for in cash. You would not have those that fall oftentimes under a copay screen. So if the drug is less expensive than the copay, oftentimes the pharmacist will charge the patient the price of the drug and not enter a claim. You would not have those. You would not have OTCs.
To enhance that medication history, there is an opportunity to cooperate between the payor database and the pharmacy database to add those additional drugs to the medication history. But remember, we have got to do it in ten seconds or less. The good news is, most payor databases would have not only the information about what has been paid, but they also would know who the prescribing physician is, they would know who the dispensing pharmacy is, and if there was an infrastructure available to seek that medication history from the pharmacy, it could significantly enhance what we are talking about here.
So we believe in a more or less hierarchical approach. You start with a patient ID n 2.5 seconds, you add to that with a medication history in less than three or four seconds, and then you initiate and extend the transaction to the retail pharmacy to augment the information.
We have been putting these medication histories into clinical settings now for about a year. We have gotten nothing less than rave reviews. It is information that clinicians have never had before.
Benefit coverage. There, we are talking about the kinds of things that one would expect in a benefit transaction, including formulary, preferred drug status, availability of generics and so forth. The information required for this, we went through a public work group process and developed a standard for a transmission of formulary. The formulary information has to be available in two ways. Some technology vendors like to download the formularies so they are present on their systems. Others want to actually have a real-time transaction to verify formulary status. Both of those standards have to be available. We are in the process of taking that through the standards processes as well.
Is national wide adoption necessary? Absolutely. The benefit coverage has to be known at the point of care before these decisions are made.
For prescriptions, the prescription process is complex. It is not simply a renewal request and a change request, but there has to be a new prescription transaction, and there has to be all of the supporting information that goes around that.
There have been no standards for a number of aspects for new prescriptions. RxHub developed that again through our work group process. We intend to take that through the NCPDP process as well.
In terms of physician adoption, I think there are a number of things to be accomplished. To start with, at the passage of the Medicare bill, we saw a notable uptick in activity among the technology vendors. So a number of us were sitting on the sidelines, wondering whether to get into the physician market again. That all changed with the passage of the bill.
One of the laments that comes out of the technology sector is, there is no adequate business model for physicians to adopt these products. So what they would say to you is, physicians are cynical. They say, we don't get paid any more whether we adopt tools and enhance patient care and save money or not, so therefore, what is our ROI for adoption of the tools.
So on the commercial side, we are exploring incentives from payors that would provide incremental reimbursement for office visits where these tools were used, and potentially, lower reimbursements where there was a reluctance to chance and adopt the tools. So we believe that such an incentive is important.
During the legislative development process, there was talk about, in the Medicare benefits itself, should there be a mandate which would require electronic submission or the drug wouldn't be paid for. The problem with that approach would be that the person who would be not adopting would be the physician. The drug not being paid for would be for the senior. That is not an appropriate incentive. So we think that the incentive needs to be built around the reimbursement to the physician, and it ought to be a positive incentive that provides an ROI.
So in summary, our industry does have to have standards. We believe that this is a very unique time. We have no doubt that this effort will succeed. As Medicare enables a benefit that covers over half the prescriptions in the United States, standards will evolve.
If the committee decides upon a standard that is different than one that RxHub uses, we will very quickly adopt your standard. So this is not a fight about anything. We are just trying to present what we think are the business challenges around the standards process.
We think the patient ID problem is not going to get solved any time soon. Unless you have some way around it, all this stuff doesn't work, period. So we have talked to everyone from Mark McClellan and the various people who are drafting the legislation and so forth about our MPI process, and we think that that has to be a part of the solution here. So we would suggest that there is a lot that we can offer there.
The third point. We must create an efficient market through which prescription drugs are purchased and delivered to consumers. By efficient market, we would suggest that today with the physician and the patient not having any idea most of the time what the benefit in place is, how can they make a rational clinical and economic decision. While we understand the opinion that suggests the patient can have anything they want and the physician can prescribe anything they want, that kind of benefit is unaffordable. Therefore, we must be able to provide a more rational economic framework to deliver these drugs.
Second to last point. Enough of the industry lack of cooperation. All of these efforts should not be used to compete or for self interest. Our health care system is broken. It is time we start working together collaboratively and build in the kinds of capabilities that we all need, and now it is time to get on with the job.
To the subcommittee, thank you very much for allowing us to come today. We appreciate it. Thank you.
DR. COHN: Thank you very much. Jack, I think you are the final presenter.
DR. GUINAN: Yes. Good morning, and thank you for having myself and ProxyMed present to the subcommittee this morning.
I as well thought I would start with providing a little background about myself and our company as a context for the remarks that I am going to make this morning. I am the chief technology officer at ProxyMed. ProxyMed is one of the primary health care EDI networks in the country serving physicians, so it is my job really to insure that we move about a billion transactions a year through our network. There are some very nuts and bolts kinds of points that I would like to make to the subcommittee today.
We do serve about 150,000 physicians, 800 payors, insurance companies, 30,000 pharmacies, 2,000 labs. We work with about 400 practice management systems. We are a combination of many acquisitions. Our experience goes back more than 15 years or so with health care EDI. We have been involved directly with the prescribing for over ten years. Myself personally, when I started with ProxyMed about ten years ago, this was the basis of the company.
The point of all this that to accomplish many of the goals that have been talked about already this morning and have been talked about in the various e-prescribing initiatives, there needs to be a solid foundation for the EDI movement of information between the various parties, and there are some very important points and goals that need to be accomplished to make that happen.
For the purpose of my discussion this morning, I am going to narrow down what I am going to speak about with e-prescribing. I'll categorize them into three pieces first, the efficient online routing of new prescriptions and refill authorizations between physicians and pharmacies.
Although it has been talked about already this morning that this really is a very basic function and not the complete breadth of what we are talking about with e-prescribing, up until now it has formed the majority of the work that has gone on with the movement of e-prescribing information, and will form a very important basis for the work in the future. This very simple goal does provide quite a bit of cost savings through efficiency for all the parties involved. So part of the goals of the act was to provide cost savings.
We have found that ProxyMed as well as many of the participants in the industry, through documented studies, that the automation of moving new prescriptions and refill authorizations between physicians and pharmacies can substantially reduce the cost of this function for both the physician office and the pharmacy. At the basis of this is replacing phone calls with an online transaction. It does as well have a patient safety effect through the legibility and accuracy of the prescription.
So although many times in these discussions this is seen as maybe too narrow of a goal or a small goal, this is a very important part of what needs to be accomplished. Yet there are some holes to even accomplish this, which I will speak about in a minute.
The next part of the way we look at e-prescribing, providing patient medication history, patient eligibility information and other benefit information is as a distinct part of e-prescribing with its own challenges, as Mr. Bradley just spoke about. Then there is another part, which is to influence which drugs are prescribed, both in a good and a bad way, but to facilitate many of the other goals specified in the act.
What I am going to speak to in the short period of time that I have is about the first point, which is about the routing of the transactions between the various participants.
Again, in routing the transactions, approximately a million a day, there are a couple of basic elements that need to be present. The routing of these transactions is the same, whether we are talking about claims, ERA, prescriptions, lab results.
We have gone through quite a bit of struggle with the recent HIPAA transformation in the claims industry. Many of the struggles we have revolve around a very simple concept: Uniquely identifying the sender and the receiver of the transaction sets.
For e-prescribing, from the viewpoint of ProxyMed and the folks that we work with in the marketplace, one, it has already been mentioned that the pharmacy facility IDs are well established. So to get that out of the way, and as Kevin Hutchinson mentioned before and Bob Beckley, the NCPDP number has been very well established as the pharmacy facility ID, whether that is the sender ID or the receiver in the transaction set. So we feel very comfortable with using the NCPDP number in this very important role.
However, on the physician side of the equation for e-prescribing, this we see as a very large problem at the moment. Physician office IDs are not standardized at all. As was already mentioned, the prescriber IDs themselves are also not standardized.
The way the ProxyMed views the routing of e-prescribing messages is that these are not routed by prescriber. In fact, the routing of these messages are done by the physician's office. For example, in the current system today, you go to the physician. One of my children goes to the pediatrician, they get a medication. It gets billed at Dr. McKee's office. They have many doctors there. They might see Dr. A one day, Dr. B the next time when they go, but all of these prescriptions come from Dr. McKee's practice.
They get sent to the pharmacy on the corner. It gets reported in the system as prescribed by whichever doctor, Dr A or B, but very importantly in the system, the phone number of the practice is reported. When I go back for a refill of my prescription for my child, when they want the authority, they are not contacting the physician who wrote the prescription, but instead they are calling the office where the prescription originated. Many times, the prescriber that wrote the prescription is not there that day. In fact, the physician might not work there anymore. But the prescription didn't leave the facility. My child is treated at that physician office. In fact, the routing is done by the phone number of the physician's office and the pharmacy system. This is the way it primarily has happened up until now.
So the point that I am making is that the routing of e-prescribing transactions should be done by a physician office or a health care facility ID, not the prescriber ID. There are different issues with the prescriber ID, and those do also need to be unique, and there are challenges there. But the routing of these transactions need to be accomplished by facility. This has not even been mentioned in pretty much any of the documents. It all seems to focus around the prescriber ID and relating prescribers to different locations, with the concept of trying to have messages follow physicians as they move from location to location. This just hasn't been our experience.
In equating this to the claims EDI practices, this is very much the claims work. We see no difference. We have been doing e-prescribing for ten years, claims for 15 years. Claims are submitted from a submitter ID from a physician office, or if there is physician information attached, it is very important to know the billing physician, but it is not the way that the transactions are routed. This is done through submitter IDs. This is in fact a huge issue we have on the claims side of the business with proprietary submitter IDs across health plans.
So today, the way this is being accomplished, it was mentioned before by Mr. Hutchinson of SureScripts, there are a number of proprietary schemes that are being used. ProxyMed has adopted its own set of proprietary health care facility IDs and physician IDs and the relationship between the both, and then with the pharmacy partners that we work with on the other side of the network from the physician offices, we exchange these proprietary IDs.
When there was only one network out there or a few, and now there are other growing networks, there is already an issue with connectivity between these. For instance, with the SureScripts network, using their SBI number, ProxyMed using their own proprietary facility ID, it would be quite a burden to have the pharmacy system vendors and pharmacies themselves try to keep track of all the various cross references that would identify which is Dr. Jack Guinan's health care facility to be able to route a transaction.
So we see this as one of the big challenges to accomplishing a national role out of e-prescribing, and we feel that more attention needs to be focused on the concept of a health care facility ID, even as it pertains to the MPI. You can establish a unique physician ID, and then say we will relate it to the many physician locations where he works, but if you don't have a way to uniquely identify the location you are referring to as the physicians move, as different physicians are related to the same practice, you will quickly lose track of where these locations are.
Again, a point already made. Physicians come and go from individual practices, but patients remain. What we have found in moving new prescription and refill authorizations back and forth between physician offices and pharmacies is that it is all about where the chart is, where the information about the patient is at the practice. When a pharmacy needs a refill authorization or a renewal authorization, that authorization request needs to go where the information is about the patient. Today, until electronic medical records are pervasive and it is very easy for a physician to get on his cell phone and look up any of his patients, that happens to be in the office where that patient is seen routinely, where his chart is. So that is where the requests need to be routed back to the facilities where the patient was seen.
So at the moment, this is to us a very clear fact of life, that the routing needs to be by facility for these reasons, and there needs to be more efforts in this area to try to figure out if it is through the MPI initiative, okay, but we feel that needs to be brought in slightly to the standardized facilities.
Another very basic part of moving transactions back and forth is about having obviously standardized code sets. You can be able to route information from one place to another, but if the content of those messages isn't clear to the receiver, then the message does no good.
A few of them I thought I would point out this morning. Again, I am pointing out the challenges as opposed to all of the good things in this short period of time, because I feel that is where this time is most useful.
As far as the prescriber code set, this has been discussed already and touched upon. I have already mentioned that the prescriber ID is not for routing of messages, but for completely identifying who is it that authorized the transaction. Currently we use the DEA number. The common practice in the industry for those of us who participate right now from the retail chain pharmacies is to use the DEA number. It was the only thing that was available.
Now, this is frowned upon by the DEA. This was not the intended purpose. In fact, there are regulations that say this is not supposed to be used for this reason. But the pharmacy systems themselves were written to identify physicians by DEA number, and that is the way the majority still are, so it is going to be some period of time as those evolve and get switched out where we can use a different identifier.
The MPI is certainly a viable alternative. It is not yet available, so there is a gap right now. So for those of us in the industry, we are filling that gap with our own proprietary scheme. Very important. If we cannot quickly arrive at a standardized code set -- and maybe it doesn't have to be one. There could be a few, but if there is not a standardized code set for identifying physicians, it will be very hard to roll out this type of EDI service nationally. We can do it in a limited fashion, maybe even get up to ten or 20 percent of the transactions being conducted. But as you approach dealing with hundreds of millions and a billion transactions a year, it is just imperative that these very simple concepts are nailed down.
The drug code sets were already touched upon earlier by SureScripts. At the moment, for e-prescribing -- and when I say e-prescribing, for the purpose of a physician to communicate to a pharmacy a new prescription, they need to identify which drug this is. At the moment, NDC codes -- in fact, in HIPAA the NDC code for a pharmacy transaction was adopted as the identifier for drugs. So the common practice in pharmacy systems today is to use NDC codes.
This is much more than was used for the ordering of drugs. It is really not viable for this purpose for e-prescribing at this time. It is at the wrong granular level. The generics, there are manufacturer specific components to the IDs, so if there are 100 generics available from 100 different manufacturers for the same drug, physicians just do not care about this. They want to see in their drug pick list one drug for that generic. When it goes to the pharmacy, the pharmacy can figure out how they want to purchase it, package size, from the manufacturer.
So there are many problems with using the NCD. The primary one is that it is at the wrong level of specificity for the drug, and creates issues in drug selection lists at the physician side.
At the moment, the way that we fill this gap in the industry is to use free text. This is fine. It is very similar to the manual process, but it does not allow us to accomplish some of the more advanced goals set forth in many of the things just spoken about. If you cannot identify specifically the drug programmatically, you cannot have programs help you assist in decision support and other types of even retrospective review of drugs. So at the moment, in the NCPDP script standard, although there is field of certain qualifiers that allow you to use NDC and other codes for drugs, the primary practice as been to use free text In fact, we have expanded the fields for the drug name, because it includes both the strength and the unit of measure many times in the free text that is sent to the pharmacy.
So there is an absolute need to resolve the drug code set challenge. This is going to be deployed on a national basis, nationally meaning not just geographically, but if we are going to attempt to get the vast majority of prescriptions written to be codified and sent electronically, this is an area that still is not -- there have been discussions for years going on with this, and there are many organizations that deal with publishing drug code sets that have been working together on this. Yet still today, there is not an eyeball alternative.
Rx Norm was in the materials that were presented to us to comment on. This is certainly something that is going in the right direction. This could serve the purpose. But this is a hole that needs to get filled quickly if we are going to really have a broad rollout.
The SIG codes, the directions for use, another area very complicated to solve, but yet something that needs to be done. Today there are no standardized SIG codes that can be used for this purpose. The common practice is to use free text. So the drift of this being that the current practice is, although a well formatted message and standardized, so it is very easy for us to make connections today using the NCPDP scripts format and to get messages back and forth, but the content of those messages for some very important fields are either proprietary numbers or are free text, and it makes accomplishing some of the advanced goals very difficult.
There are conversations going on about codifying the SIGs and coming up with standard SIGs. This is not something at ProxyMed. This primarily involves the moving from transactions from point A to point B. Just pointing out that this is one of the challenges and one of the code sets that needs to be focused on and established for a broad adoption as well as, if you are going to retrospectively go back and take a look at prescriptions or even prospectively look at what it is you should be prescribing, you cannot have programs help you do this if there are free texts in these fields.
Moving on to something which is a little bit happier subject, message formats. If we are moving transactions from point A to point B, we have to worry about who is sending them, the contents and the message format. ProxyMed has been working with NCPDP since the inception -- before script, but since the inception of script for e-prescribing. It is a very well established format. It serves all of the basic purposes for moving e-prescribing transactions from point A to point B. It has been widely adopted for new prescriptions and refill and renewal authorizations.
I would say across the board, I can't think of a participant in the industry right now that is using something other than the script standard for the message format of these type messages. Physician office software vendors, the hand-held vendors have been able to adopt this. It really is no burden on these folks to use this standard. It is a very strict standard. It follows a very basic set of rules. The pharmacy software vendors, likewise.
It has not been our experience ever in dealing with connecting a partner up for a network that they said, the NCPDP script standard is too difficult to deploy, isn't there something else to use. This has just not been an issue, and since this has been going on now for seven years, I take that to mean that it is easy to deploy, and it is not a burden whatsoever. In fact, it is well developed and easy to deploy.
It is mature. Although we are having these hearings now and we have been having hearings like this for awhile, and we are talking about the future, in practice it is a mature standard. We have been working on this for over seven years.
The process by which this standard has been developed and continues to be maintained is a very good one. NCPDP is a very broad organization. There are participants from all aspects of the marketplace that actively participate in work group 11, the script work group, and spend at least four times a year at the quarterly meetings. In between some work groups there is a constant dialogue that has been going on for this many years, and will continue. So in our opinion, to start again and to adopt something else for this purpose, for the movement of the messages, that would be quite a burden.
If we as a network provider had to go back to the software vendors we work with from both sides of the equation and say, well, we are changing the rules of the game, the standard is changing and you have to recode, -- we have HIPAA, which has been for the purpose of the network quite a challenge, and we are struggling just to keep going with the daily business of getting physicians paid their claims, because we switched the basic format of the message. You have hundreds of software vendors having to modify their software, a very risky proposition.
So we would suggest that switching from the NCP to script standard as the basis of the e-prescribing message format would introduce this type of risk into the process again, and would be very negative to the folks that have spent this amount of time getting to where we are in the industry today.
The organization itself, NCPDP, as well as the message format itself, is a very good starting point. It has already been spoken about that it does not cover all of the bases. The format today does not allow the transaction types that are envisioned. The transaction types that are there do not include all of the data elements. There are code sets missing. Given that and given those challenges, we still feel very strongly that it forms a very good basis and a jumping off point for the future work, as opposed to going back to the drawing board about the message formats.
So in conclusion, thank you very much for the ability to present. This was very much nuts and bolts, but as we found and we have gone through over the past year a transformation of the financial transaction set by introducing standards, and the pain that has been inflicted, because there are still some holes in those financial standards, we hope that we could put a lot of emphasis on the basics, get the infrastructure in place. Let's make sure we can move messages well back and forth, concentrate on codes that will help us build for the future and offer some of the advanced functionality.
Thank you.
DR. COHN: Thank you all, it has been fascinating testimony. Let's take questions from the committee. Jeff, would you like to start out?
MR. BLAIR: The first thing I want to make is a comment, before I have my question. I would like to applaud what all three of these networks, RxHub and SureScripts and ProxyMed, have done to be able to offer additional efficiencies, improve quality of care and reduce medical errors by the work that you have done. And you have done it in an environment before there were national standards that were really set forth or endorsed by the federal government. There is just a tremendous amount of value to what all three of you as networks have set forth.
I think you can wind up seeing that in the MMA, it is wanting to explore whether there is additional functions that can be included in e-prescribing. Among these I think are making sure that the formularies and the health plans are not restrictive, and that the physician is given an opportunity to respond rapidly and quickly to preauthorizations, to give a preauthorization.
So the genesis of my question, and I guess I have two, one is with respect to the preauthorizations, and the ability of each of your systems to feed back that information to the prescriber, so that if a particular drug is not in the formulary, that the prescriber has an opportunity without any impediments or barriers to come up with an alternative.
The second one is -- and I guess I am morphing into three -- the other one is with respect to medication histories, that the prescriber gets access to that information to be able to make a judgment. Then the third is with respect to what is generally referred to as DUR, but many in the health care provider area seem to call clinical decision support for drug to drug interactions, drug to allergy, drug to lab, that that information gets fed back to the prescribers.
Could you please educate us as to the degree to which this information gets fed back to the prescriber, so that the prescriber has the opportunity to make a modification in the initial prescription according to the prescriber's wishes?
MR. HUTCHINSON: The preauthorization checks in today's world is done primarily electronically at the pharmacy level. In today's world, those calls then, if a preauthorization is needed or required, then those pharmacies are calling the physicians' offices or contacting the physicians' offices in some form or fashion and gaining that preauthorization.
SureScripts as a company is not in the business of the financial transactions or in the preauthorizations for eligibility or benefit transactions. They are more focused on the clinical routing and the prescription information between the physician's office and the pharmacy. So the preauthorization question at this time is probably better for Jim.
MR. BRADLEY: Why don't I try to address all three very quickly, and then we won't be passing the mike back and forth?
In terms of preauthorizations or other kinds of messaging to physicians, RxHub developed something we call a point to point encrypted transaction, in which the physician's office and whoever is trying to authorize the use of a service can exchange messages of any format and so forth. So we didn't see a standard for pre-auth. We developed -- you might think of it as an encrypted envelope, where that could be populated with the information around managing a pre-auth process.
There is a bigger issue here, though. I'm going to go back not necessarily to work done at RxHub, but work done at a startup that -- it was aveton.com, for those of you who remember when I was doing that. We determined that you couldn't be very invasive in the physician's work flow before he took his chosen human interface and threw it against the wall, sometimes harming the patient, and we don't want that to happen. So the first patient safety opportunity is to not disrupt the work flow.
The way we did that is, we took the rules -- and let me just as an example a prescription for a drug in which there are a number of drugs available which might include a preferred brand of drug, a generic, and then some that wouldn't be covered at all. We felt that when the physician was presented with a screen in which they were able to order the drug, that status of each of these drugs ought to be readily apparent.
So if there is a generic alternative, for example, or a preferred brand of drug in the therapeutic category, that is one mouse click or one point that gets to that drug, and if there is then a desire to use an alternative drug, as long as the physician and patient are informed of the consequences of that, which may be total lack of coverage for the drug, could be a higher copay at the pharmacy, whatever. The physician is given the opportunity to order any drug they want, and then to enter information informative to the pre-auth process.
Basically, that shouldn't stop the work flow at all, meaning that that should initiate a process with the payor or whoever is going to authorize it is not invasive to the work flow or practice.
What we found is, most of the time that would facilitate step therapy or other approaches, which would start with the lesser cost drug and work up toward it. The primary principle here though is, there has to be a patient choice for any drug available, and the physician has to have the ability to prescribe any drug available. It may take two or three mouse clicks, but they have to have the ability to do that.
I think your second question was about medication history and how that is made available. In the same scenario, the way we approached -- and again, it is going to differ, depending on the depth of the application that is running in the physician's office, but the way we approached it was, that patient history was downloaded at the point in time that either the appointment was made or the patient checked in for the encounter or the office visit.
It requires patient permission. The way we approached that was, on a blanket basis, the patient signed permission for that download. Then each time they came in for a new office visit, there was a work flow process that got the permission again. That is very important. Then at that point, the patient history was downloaded in a transaction format into the system.
So when the physician chose to prescribe a drug, and I am getting over into the DUR process here a bit, the drug-drug, drug-disease and other kinds of contraindications would be screened against the broad patient history, not just the drugs that this physician knew about because they were prescribed in this practice. That was done. Today we have proposed a transaction format for medication history. We also began to offer medication histories in the inpatient environment. The way we have done it in the inpatient environment is to use HL-7, which is the standard that hospitals know about.
We offer two flavors. One is a text report, the other one is a transaction. The text report, for those hospitals who don't use automated CPOE systems, and the transaction report for those that do. Again, same ten second approach. What it required us to do is actually get inside the firewall of the hospital and basically insert a transaction through the ADT system.
I think I covered all your questions, Jeff.
DR. GUINAN: Yes, the critical factor on the preauthorization is to allow the physician truly to select the drug, to provide information to the physician in the form of decision support. So not to actually force the physician to have to jump through hoops to select the drug that he wants, because then you have to duck in the way of the hand-held device, but rather to present the information in a concise way so that the physician can use it to make his decision. But in all cases, it has to be the physician making the decision.
Now, there are two models that have been deployed in the marketplace for this. One has been, there are a number of databases and companies that have published databases with formularies and preauthorization type information, that gets distributed on CDs out to the physician practice. It gets updated about once a quarter. For the most part it stays correct enough; these formularies are not changed all that often.
That is quite a challenge, distributing these CDs. This is something we participated in for quite awhile, still participate in, as a matter of fact. Our other hat is being a software vendor, besides a network.
This is not really a way to go. Sending out CDs every quarter with this amount of information and worrying about version control out of the physician practices, this is not all that good. So adopting an online transaction that allows for a request response for this would be much preferred.
There is not a standard transaction for this today. There are folks that are working in the marketplace such as RxHub. They are putting forth a transaction for this. But our opinion is that this information will be much better deployed on a broad scale if it was done in a request response type of situation. So it is important to get that transaction standardized.
As far as histories, pretty much the same point. It has been proven that physicians find this very valuable. There is not a standard yet. ProxyMed has participated in sending patient prescription histories to physicians in a proprietary format, based on the script standard, so the basic segments that you needed that were in script, then we concocted our own message format.
There has been quite a bit of work done at NCPDP about this transaction type. This has not been formalized, and it is not part of the official standard. So I believe that also, NCPDP could very well be the jumpoff point.
However, when you speak to the EMR vendors, as a rule they are much more used to using HL-7 to represent medication history in their systems. So it is very important -- and this is going on right now between NCP to PN HL-7. We just need to make a decision. Are we going to go with the fact that most of the information in the EMRs is stored using the HL-7 as the input, and then come up with an interface to script, just make it the HL-7 period and that is what we are going to deploy? Or call it script and then have to worry about interfaces in the physician practice. But our experience has been in dealing with the EMR and truly clinical products for these types of histories, they are used to HL-7 interfaces.
There are many, many interfaces built to the inpatient setting, sending this type of information out to the outpatient setting today. So I would call it at the moment a 50-50 proposition. But that is a decision that needs to be made. Either one could be used. Important to get a decision made so that we can move forward, so the software vendors have -- it takes a few years to get software products built, QA'd, actually deployed out through their release cycles into the physician practices.
As far as DUR, pretty much the same comments as the patient history. There are databases that are deployed via the CD out to the physician office today, from folks like MediSpan and First Data Bank. These work fine, but it is a challenge to be constantly distributed and updating this information out across 200 -- so if you wanted to deploy to every physician practice, this is a challenge. An online type request response transaction wouldn't be much of a burden in drug deployment.
MR. BLAIR: Can I echo back to make sure that I understand this correctly? I think I have heard that standards don't exist for communicating on an online, real time basis either medication history or the formulary information to allow for adjustments to -- if there was not preauthorization, to be able to obtain preauthorization, or DUR information, all of these to the prescriber.
Now, there have been a number of things that have been done because these standards have not been in place to try to accomplish this. It is possible that we don't have to have national standards for all of these. I think that is something that we are going to continue to explore. But I think I have heard from you that standards don't exist in these three areas today.
MR. BRADLEY: I think it is perhaps better news than we may have perhaps led you to believe. In the ambulatory side for medication history, basically that medication history transaction is inheriting a lot from script. So I am presuming that in essence, that will successfully evolve out of the process with NCPDP. I don't think that we are going to have much of a conflict about it.
On the hospital side, on the clinical side, I believe we are going to have to learn to speak HL-7, because the magnitude of the problem to get those clinical systems changed to match our ambulatory view is not going to happen. But again, I think that we are nearly there in terms of being able to pretty clearly define for you what those transactions look like. So I don't think we are in trouble on that one at all.
MR. BECKLEY: When you are talking about, as the prescriber is in the act of prescribing or pre-scribing, as Jim said, you are correct, there is not messaging going on right now. After the fact, the script standard does support the pharmacy communicating back to the prescriber, I need a prior authorization. We have found a DUR. They are not doing it right now. The potential is there for medication history.
But two of the three you mention, again, it is a little bit after the fact, but the pharmacy can't communicate those back to the prescriber. The question is making that proactive.
MR. HUTCHINSON: Two comments. On the prescriber for medication history -- and Jim and I have had lots of discussions about this, we firmly believe there needs to be a level of partnership in the industry around providing medication history. There are medication history databases that exist in the pharmacies, in the payors, in the PBMs as well, that need to be combined. You have cash transactions, you have uninsured.
Of course, you are here today talking about the Medicare and the drug benefit plan, but we all know this is a standard that will be implemented as he described as a whole. So we need to make sure that when we look at medication history, that we look across a multitude of databases, where medication information exists, to be able to combine that.
The good news is, the pharmacies are coming together to say what do we need to be doing. They have started that planning process now of how to provide level of medication history to the physicians upon request.
The final comment, without repeating anything that has already been said around the DUR process is, we firmly believe that the DUR process is not a single stage process. It is a multi-stage process, in the sense that there are -- a DUR is performed at the physician level using technology in these drug databases for drug interaction checking. But you have another stage which occurs at the pharmacy that occurs today at the pharmacy before anything is dispensed against their own drug databases within that pharmacy store, and you have a third stage where that DUR is performed against the payor and PBM database as a part of the claims process. So you really have a multi-stage process with the DUR, so that we don't point to one direction and say, that is where it should be.
MR. REYNOLDS: First, I'd like to say, excellent testimony, and you really summarized it for me. Mr. Bradley, you mentioned the PBM indicator in your patient identifier. Is that just the name of the PBM or is that some kind of an identifying number plus the name of the PBM?
MR. BRADLEY: Let me just give you a little more context on the challenge. The challenge as we started working through this problem at RxHub is, our owners were three major payors or agents of payors that competed with each other. So what we had to do is, we had to come up with a combined structure that didn't challenge the competitive issues that they had amongst each other. So we couldn't store too much. We couldn't become the next evil PBM in the ether or anything like that. We had to really work through a lot of it.
So we wanted to come up with a minimum data set that would allow us to perform the patient identification function. So the five demographic elements identifies the human being reliably. Then we had to store what was a minimum amount of information around, how do we direct to then where the drug coverage is, without replicating that information.
So what we did is, we identified the actual organization, so it would be CareMark, and then the unique identifier which they use to track that individual. That is all we have. It does imply -- and this is the same for medication history and everything else -- is that people who participate in a network like this have to provide real time response to a transaction.
So what happens is, the five demographic items identify Harry Reynolds, your drug coverage is Blue Cross of wherever. We then point at Blue Cross, we have the unique identifier, and we hand off the transaction to them that requests a med history on you. Then they have to have a real time response to us -- we like it in less than three seconds -- where that medication history comes back and we deliver it.
We don't open the envelope. We don't store medication history. We deliver it to your clinician after you have given permission.
MR. REYNOLDS: Mr. Guinan, your discussion about the facility versus the prescriber, do you feel that by staying at the facility level but only including the prescriber in the actual record, will help with secure IDs and the other things that we are all going to have to deal with as we move into the next level, which is, you actually submitted the prescription?
DR. GUINAN: That is correct. To us, they are two very different things. The routing element of how we know where to send the refill or renewal authorization request from the pharmacy is to the facility. Attached inside that message is a piece of information, no different than the drug is, who is the authorizing prescriber that started it.
Likewise for a new prescription when it goes from the physician office through the pharmacy, it is very important to record the facility it came from. Included in that message happens to be, just like the drug or the SIG, the prescriber that authorized this. But it is not the prescriber that dictates the EDI routing of the message.
MR. REYNOLDS: You would say that a facility -- as we move forward, a facility might have one ID with many prescribers underneath it?
DR. GUINAN: That is correct, very similar to the financial transactions in health care for claims, where we have a unique submitter ID that is associated with every service location. In fact, when we submit claims, it is that submitter ID, not the rendering, billing, referring physician IDs. Those are just information in the claim. It is the ID of the location that is all important when it comes to the routing.
MR. REYNOLDS: One last question. The last one is, as you look at the different settings that we have been dealing with, obviously you are dealing -- in the physician's office, we are dealing with somebody that is an inpatient. But a lot of doctors actually visit people in the hospital as they are leaving, write scripts and leave. How do you see in this e-prescribing that -- that is a significant situation that exists. How do you see that occurring in this e-prescribing world?
DR. GUINAN: Well, in terms of just the inpatient to the ambulatory, one of the number-one drivers, we think -- we are at the beginnings of this, but we think one of the number-one drivers of patient medication errors is the absolute lack of continuity between ambulatory care being provided and then what happens in the hospital and then back out again. So that is problem number one, so that has to be addressed.
The thing that is very problematic today is that the hospital tends to choose a formulary based on some form of volume purchasing arrangement. They use those drugs as part of an inpatient episode for which they are at risk, on a per case or per diem or whatever basis. When they go to discharge, most of the time the discharge script is written on the ambulatory drug benefit. So a different formulary applies.
The error potential happens because we believe that patients, before they even see their attending physician before they get home, go back to the drugs that are in their medicine cabinet, not understanding that there is a potential for therapeutic duplication and so forth.
So we believe a couple of things. One is, if there is an ambulatory prescribing process as part of discharge, it needs to be equally aware of the patient's history, benefit rules and so forth, when the discharge scripts are written, because if not, we have the same potential for error. We also have a cost issue. For a Medicare patient, that discharge script would be covered perhaps by a different benefit than the benefit that covers the hospital stay. It is going to be required that Medicare communicate the appropriate formulary and other information at that point in time.
MR. HUTCHINSON: From my perspective, there are a couple of things. I would respectfully disagree with my colleague from ProxyMed on the office based ID versus provider ID. We in fact do implement the provider ID down to that level for the very specific reason that you mention, to allow mobile access for physicians in multiple locations to be able to prescribe medications.
There are many different types of systems out there, and we had to design a capability to accommodate those different types of systems, whether those be mobile devices or whether they be client server applications or web-based applications, or where they may be. It is important to know where those prescriptions are coming from. It also matches up with how the pharmacies look at the information on their side with respect to the provider information within the pharmacy databases.
The challenges on the inpatient on the ambulatory side, however, is the fact that the NCPDP script standard as an example, as mentioned earlier, is not necessarily prevalent as the standard of choice. HL-7 is the standard of choice. Now, with the prescribing vendors, absolutely, the NCPDP script is prevalent within the ambulatory environment. Within the traditional and more established electronic medical record companies that are out there, the HL-7 is the traditional standard that they look at. In many instances, they are not ready to accept the NCPDP script standard.
We are looking right now at a partnership between HL-7 and NCPDP to help us do some level of translation between the HL-7 standards and the NCPDP script standard. There are many, many of the inpatient system vendors that exist out there today that want to send their prescriptions electronically from the hospital setting to the patient's pharmacy of choice, as well as from the emergency rooms to the patient's pharmacy of choice. They are in the process of connecting into the network today.
DR. STEINDEL: First a comment and then a question. I'd like to thank ProxyMed for introducing the routing issue as an issue that needs to be considered and looked at. In light of SureScripts' comments just now, we can see it is a very complex issue. CDC has been trying to raise this issue for a long time I'm glad that it came out in this session. Thank you.
Now to my question. One sense that I got from both your presentations and from reading the written testimony of various people today is questions concerning medication coding. One thing that we are supposed to be doing is identifying standards to use. As many people in this room are aware, last year this subcommittee spent a lot of time looking at standards for medication coding, both through the CHI initiative and our NCVHS PMRI terminology initiative, and recommended a series of standards.
What I am hearing both from your testimony and what I am reading in written testimony is that there appears to be some tension as to exactly what is the most appropriate set of codes to use for ordering drugs. In some cases, we talked about NDCs, because that is actually what is being dispensed and ordered. In some cases we talk about the clinical drug as expressed by Rx Norm. I think my basic question that I have for the group, and then there is a little secondary question concerning the SIG itself, is, at the time these were presented to NCVHS, they were being presented as in development. Do the people in the panel feel that once the system is fully developed, will that meet the needs of the medication coding, or should we be looking at something else?
By fully developed, I mean in essence, if Rx Norm is fully populated within the UMLS and tied into the NDC either as it exists today or as it is being evolved into, or we are hearing that it is being evolved into, will that meet the needs of medication coding, will the introduction of NDFRT physiological access help in the ordering of drugs, and will the structured product labelling as proposed or envisioned by the FDA, which is as I understand coming into effect in probably two phases, first just from a header point of view with text afterwards, but eventually will a fully computable label, would that type of medication system, once it is put into place, will it meet the needs of the e-prescribing as described in the MMA?
Then as a followup to that, it is somewhat corollary to this, because it has to do with coding. It is a very quick one. It is the question of the SIG. Now that SNOMED is relatively available, has any of the groups looked at SNOMED as a source for that information? Because it appears to me that the codes are there, and they could be embedded in any of these terminologies that we are talking about.
So that is somewhat of a followup, I would like you as Jeff pointed out to address the first question as your main point or comment.
MR. HUTCHINSON: I'm going to let my colleague, Ken Whittemore take that, my pharmacist friend.
DR. WHITTEMORE: I'll start in reverse order. I'd say as an organization, we have not spent a lot of time looking at SNOMED, and that is something that we will have to take a look at. So that addresses the SIG issue.
In terms of Rx Norm, we recently became aware of that, and have started to analyze it. I would say -- and this is very tentative in terms of giving a response -- that if there was a connection made through that particular database to the NDC code, then I think probably as an organization we could make that work. But again, it is a little premature for us to -- I don't think we know enough about Rx Norm yet to be able to give a definitive answer.
MR. BRADLEY: Let me make an attempt at this with the caveat that I wasn't smart enough to understand your question fully.
Everything I know is from this group of clinicians and pharmacists and others that worked with me at Abeton and still are alive and well at MacKeston. So I know what they are working on. What I would answer you is, yes, there is a need for a standardization of the ordering process. The challenge is that in the work flow for the physician and in their minds, they don't want to deal with the complexities of NDC coding down to the component level. That is more of an inventory control problem at the pharmacy.
So they think, if I picked up this right, that Rx Norm is the answer to that, that there will be a simplified ordering process. There will still be an NDC coding process when the drug is dispensed at the pharmacy, and the two will be tied. But the physician can prescribe a generic without having to get into who the manufacturer was, can actually delegate a piece of that, with the idea that the closed loop is when the claim comes in to the payor with a very specific NDC code, as to what was dispensed to the patient.
The answer is, they do believe that SNOMED is the answer for the coding of the SIG, period, and are broadly adopting SNOMED within their systems, or at least that is what I hear the clinicians saying. So if the rest of the vendors go that way, game over, that answers the question there.
I hope that was helpful. I can introduce you to the people working on this that know something about it. I know nothing about it.
DR. GUINAN: I'll just add, I am certainly not an expert on this. I would say that the stated goals of Rx Norm and what they are hoping to accomplish is what is needed. The requirement though is an absolute interface to NDC, because there is no way that a pharmacy can operate its business without -- if you want an online order on the front end from a physician, without tying it to their inventory. So the inventory ordering is going to continue to be done through NDC, their claims adjudicated by HIPAA using the NDC code. So if something like Rx Norm is going to be adopted, it has to be interfaced directly to and be able to uniquely identify which NDC is going to be dispensed.
MR. BRADLEY: Just one more comment through Jeff. Dr. Bob Elson, who was with me at Abeton, then MacKesson and now RxHub, and Dr. Kim McCowski, are our experts on this. Jeff, I know you are in dialogue with Bob all the time, so I would pass that on to him and ask him to weigh in on the subject.
MR. BLAIR: Not all the time, but I am very pleased to have him educate us. Anything that I learn from Bob, I pass on to the subcommittee.
MR. BRADLEY: He would be our expert on the subject.
DR. WHITTEMORE: I think the challenge from my EMR days is, yes, a lot of the EMR companies several years ago started implementing the capability for SNOMED, and actually giving provides the option of which coding mechanism they wanted to use. However, the challenge has been physicians' willingness to accept that standard as the standard to be used within those systems.
So I think even if we have it as a standard, from a technical standpoint we still have a hurdle to get over to get physician acceptance.
DR. STEINDEL: This is a bit of a followup. All of you addressed the question of the NDC to the Rx Norm transitions, and I think you did a very nice -- I thank you very much for those comments.
Do you have any comments on the proposed structured labeling and how it would fit into this process, especially when it becomes fully comparable?
PARTICIPANT: Just in general, not for the SIG, the FDA label contains a tremendous amount of information on the drug. Once it becomes understandable by a computer system, I think it has a lot of impact on what we are talking about today.
DR. GUINAN: ProxyMed does not participate in that specific aspect of the process, so we would have no --
DR. STEINDEL: Thank you.
MS. TRUDEL: I am hoping you can address the distinction that I thought that I heard Jim Bradley make between eligibility information and formulary information. It seems to me that MMA considers them to be part of the same concept. I thought I heard you say that the 270-271 appeared to be your choice for eligibility. But then I heard someone else say that there was no standard for formulary. So I guess I am wondering, should they be part and parcel of the same transaction, and how do you feel that they link into the existing script standard?
MR. BRADLEY: I'll start this. The eligibility piece of it, what we are referring to more along the lines of an insurance eligibility, says there is a drug benefit that applies, with some indication of what the drug benefit is, meaning some pointer to a patient specific formulary or preferred drug list or whatever, so the physician system could point at that.
When you get into formulary, the formulary transaction is a bit different. I'm trying to figure out the best way to contrast this. There are two ways that formulary information is made available by most of the technology vendors. One is in real time, in which a transaction -- here is the patient, here is the drug I am choosing to prescribe, is this on the formulary. The problem with that transaction, while real time, is that it forces the physician to shop for a drug. It is very invasive to the work flow. It really slows the work flow process.
So most of the applications that better suit the work flow of the clinic actually download batch formulary loads from whoever the payor is with an indexing structure that allows a pointer. So when you get the patient, you point to that formulary database.
So what we had to develop were two standard transactions, one that had to do with the downloading and batch of these formulary records, the second a real-time transaction that said either this drug is on formulary, not on formulary and so forth. Those are two different transaction standards to support a process, which I agree with you should be combined. This is the drug benefit, here is the formulary pointer that applies at a patient specific level, and then hopefully to aid the work flow in the clinic, we are not shopping, is this drug on formulary, is that drug on formulary, is that drug on formulary. That we are pretty sure doesn't work very well.
Did I answer your question?
MR. BECKLEY: Karen, on your last piece you said what about the script standard. It has the capabilities. It has insurance information in it. There can be a message to check eligibility and bring back formulary at the same time.
Again, you run across issues of speed, how long does a physician want to wait for all that information and come back. But it could be sent in advance. It could be one message. The capabilities are there. It just needs to be implemented and people need to agree to use it. The main points, I'm sure, need some fine tuning, but more than a foundation is there. Quite a bit of the framework is there to do it also.
DR. GUINAN: I will add that ProxyMed is one of the primary providers of physicians getting medical eligibility information back. It is a common practice for offices, hospitals, it doesn't matter what kind of setting to, when they are getting ready to see patients the next day or whatever their process is, pulling charts and so forth, to shoot off a large batch of eligibility requests. That then comes back and they match it up with the schedule, here is all the information we know about the patients.
Well, when we get those back today from the payors, there is everything on there you ever wanted to know except for medication prescription coverage. It seems natural to us, and part of the same process, as they are preparing for patients the next day, it should all be part of this one request. When they do an ANSI 270-271 as mandated by HIPAA, that we should figure out a way to include the prescription coverage eligibility, not formulary.
So the second part of the question, this does not include which drugs are eligible for how the physicians should make that choice, but rather, what sort of coverage do they have, and what kind of rules are going to apply. This is going to get much more complicated, depending on how all the benefits are implemented under the act. If patients can move between various entities that can provide coverage to them, it is very important to know which one they belong to.
So eligibility and the formulary, two different things, and we view it that it should just be part of the 270-271 as part of the normal practice they do today for pulling patient eligibility.
MS. TRUDEL: Thank you.
MR. BRADLEY: One quick followup. Part of the focus more on the insurance industry's traditional standards, we have a coordination of benefits opportunity for the first time. When you enroll this population, there are going to be a number of things we can do to coordinate coverage, with pretty significant implications. But the adjudication of COB requires a certain amount of information that isn't necessarily available in some of the standards that are being tossed around. The process is very complex, and with the high volume of drug transactions, you can't afford human intervention in the COB process.
So my thought is that the 270-271 gets some of that information better and is better able to allow us to adjudicate a broader COB approach that includes drugs. That is part of the reason we went there.
DR. COHN: Could one of you explain to me a little bit more about in Medicare Part D, how it is going to work with COB? I hadn't really -- my understanding of the Part D benefit is that COB will probably be a minor if any piece of this. Can you clarify?
MR. BRADLEY: Yes. I worry about the commercial world. Whatever you adopt will close over.
The other thing is, let me just recount the first time I met Mark McClellan. I was starting to explain to him about the payors' issues with electronic prescribing. He respectfully stopped me and said, look, I understand all that. I want to talk about the direct restructure. We think that over time, coordination of benefits is going to be an important part of a public-private partnership with how Medicare drugs are administered.
So to the extent that private risk parties and other insurance vehicles interoperate to deliver a drug coverage to a senior, there may well be a COB opportunity with Part D. So again, I am thinking about the future and what it brings.
DR. COHN: Thank you.
DR. HUFF: Since everybody has been talking about HL-y, I have to disclose that I have a bias for HL-7. I am the former chair of HL-7, currently a vocabulary co-chair in HL-7. So put that in context.
My question relates to the kind of clinical information that -- we have talked variously about medication history and quote, medical history, that would be transmitted. It is not 100 percent clear to me what the scope of that should be and when it is flowing, whether it is flowing from the physician to pharmacies or physicians to benefit managers. Could you clarify what your vision is of what -- is it purely just medication history, or do you want lab data and diagnostic information, that kind of information? When doe it flow and who does it flow to?
MR. HUTCHINSON: The intent is what is available today and what is going on down the road or in the future, as Jim represents, that we need to be focused on. Today, obviously HL-7 is very critical for lab result delivery into EMAR systems as well as into electronic prescribing applications. That is the default standard used in the ambulatory care environment for the exchange of clinical information even between systems, whether between a hospital system and an ambulatory setting system or a lab system in the ambulatory setting system. So I would agree with you. In that sense HL-7 is the default standard in the ambulatory care environment.
Around medication history, in today's world of what is being implemented, it is the payor to PBM delivery of medication history information to the physician. In a broad scale manner today, in the DUR process that occurs in the pharmacy, it is not using an HL-7 standard. The medication information is delivered in the form of an alert during the process of a DUR alert. However, the history information itself is not delivered directly to the pharmacies, which we would like to see that history information delivered to both care providers, the physician and the pharmacy. I think that has to be an industry partnership between the pharmacies, the payors and the PBMs to be able to pull together a complete medication history for patients.
MR. BRADLEY: The context of the medication history that we are talking about, again this dates back, was first implemented in Cocomo, Indiana in 1999 with Medco. There, the encounter in the physician's office was enhanced by a downloading of the medication history from the payor database. So this downloading occurred between the payor and the physician's office and was stored as part of a record there.
The breadth of that was again with the patient's permission, all physicians prescribing, all pharmacies dispensing. It is still today. Each time a physician is introduced to it, they feel that it is data that they have not had before.
Now, in terms of the broadening of that, we have been approached by one national lab company to say, now that you can identify the patient in a quarter of a second, we believe that we could participate in such an information routing as well. So the idea that lab values could flow through the same pipe.
The problem on laboratory though is, if you take the large national labs, for example, and put their combined business together, I think it is 30 percent, maybe 35 percent, of the world. An awful lot of things still happen in the hospital, happen in the physician's office, or happen in regional lab companies.
The thing that has made medication history effective for us thus far is the significant consolidation of the PBM industry. Three pipes get you to 75, 80 percent of the commercially insured population. So therefore, physicians are willing to try the transaction in an attempt to get the medication history, because most of the time we can deliver it. We aren't there with some of these other forms of data yet.
DR. GUINAN: I'll add that the HL-7 is the primary transport format of lab data amongst physician practices, hospitals and so forth. Today, the script is the primary format of the messages for e-prescribing. It doesn't seem that to have a physician's office receive both lab results information as well as medical records, the two have to be. The EMR companies and practice management systems have some well-established HL-7 interfaces. The script standard is very easy to implement.
It has not been a challenge to get folks that already have HL-7 interfaces to implement script for this data stream coming in. The data is not stored in HL-7 or script once it gets there; it is stored in whatever internal representation in their database.
So my point being, it doesn't seem that there has to be the same transport protocol for lab and prescription. It would be very nice if through one request, the physician could go out to something in the sky and say, give me all the information about this one patient, but that might be asking too much.
So in the meantime, if payors are able to distribute medication histories via script and lab results come from the labs via HL-7, it just does not seem to be an impediment for it to all end up in the same EMR in the physician's office. So my point being, I don't think we need to move in the direction to try to have to marry the two together. They both can stand on their own.
DR. WHITTEMORE: If I could just add one professional issue, as we mentioned earlier, SureScripts was created by a Community Pharmacy. Community Pharmacy for quite awhile has felt that their ability to counsel patients properly as they are required to do so by law and board regulations, that would be enhanced if they could get laboratory information and diagnosis information. So as the committee contemplates this kind of messaging back and forth, I would certainly hope that that would be part of the process that it will consider.
DR. HUFF: In that regard, I guess the thing that seems hard is, the messaging is actually pretty well understood. We know how to send messages for lab and/or diagnostic information. It is that -- to me, it is how many copies do we need. We have the information, the diagnostic and lab information eventually ends up in the EMR in the physician's office, and then it gets copied to the pharmacist and then to the payors, and how many copies of this data do we need, and how do I recognize duplicates of the data if it is requested again.
It now looks like the pharmacies are maintaining an EMR that is essentially a duplicate of what is in the -- is there a boundary on that? Is there some way to manage and regulate, or do we just do it?
DR. WHITTEMORE: I think clearly there would have to be some kind of a boundary. How far would you go down the road in terms of an EMR, in terms of what information a pharmacy would need in order to do what they do. I would think that would be part of a dialogue that would take place in the standards setting organization.
MR. HUTCHINSON: But I would add to that, that unlike my examples previously on the banking industry, where we may use one bank, in the health care world, as you know, patients are all around in multiple places in health care. I think you are going to have multiple copies of information in different databases, because a patient is in multiple health care organizations, whether that be family physician or a cardiologist or a hospital or a pharmacy or other areas. It is a matter of what level of information is needed at which points of care to improve the safety and efficiency of the process.
The inefficiencies that occur around this today in the pharmacies is having to call the physician's office to make sure a lab test has been performed, to find out what the results are, and to handle that with the payor or PBM to be able to dispense the medication, and have to clear up that prior to. If it is delivered electronically, it reduces another call, and that is obviously a much safer transaction as well.
DR. STEINDEL: Over the last couple of years, this subcommittee has heard numerous testimony from deliverers of alternative medicine. I am recalling Jim Bradley's distribution slide on assembling a medical history from various components. In no place in that did I see a direct link to alternative medicine providers, if they weren't in a pharmacy or something like that. Does this pane l have any comments on how this subcommittee should consider that?
MR. BRADLEY: I'm not sure there is an infrastructure to arrive at that information, other than one thing that we haven't talked about this morning very much, the patient and their role in fleshing out what this medication history looks like.
So one thought being that the patient needs to also contribute. In the absence of any other sort of information, it would be nice to know about aspirin therapy, it would be nice to know about other alternative medications, vitamins, that the patient may be taking.
So I think there is an opportunity. I get asked this about once a week. There are a number of organizations that are advocating now for a patient record, patient controlled, that can be contributed as part of the information base here. We are seeing a movement within the health insurance industry towards more consumer directed care, to make them more accountable for how they use the health care system. So I think these things work hand in hand. We need to figure that out.
The issue with seniors, I'll just give you an example. My mother last week said, I can't understand these discount cards, can you help me. I said, the reason that they exist is to make you more sensitive to the cost of providing care to you and to provide you with some mechanism for relief. She goes, but I don't understand. Then I realized I couldn't help her.
So anyway, my point being that seniors are sometimes confused. We need to help them help us. The woman I am talking about here prevented my father from a very, very serious medication error recently, because of lack of communication between the physician and the pharmacist, that didn't occur, and almost caused a double dosing of a very significant medication.
DR. GUINAN: I'll just add that I think it was actually an omission that we did not talk at all about patients when we were speaking before. In fact, when you talk about providing medication histories to physicians, the patient will want to know what is that physician seeing.
This has been one of the challenges in getting that service deployed, has been getting the authorization from the patients, because before you can get all pharmacies, all payors, all medications to the physician, the patient has to say, this is okay for this doctor to see these other medications. Although physicians of course want to see this, they said it is very valuable, the patients are going, wait a second, I'm not so sure I want this physician to see what is going somewhere else, as well as coming from a family that is quite a big user of alternative medicines, I don't think my mother wants her physicians to know all of the alternative medicines, because her primary physician doesn't like this and yells at her about these things.
So patients absolutely are going to want to see what is in the content of those medication histories that are being passed around. That just leads further to more of a patient centric model, and the patients controlling what is in the content of the medication histories, which is a whole other can of worms that get opened up, but might be unavoidable.
DR. SCANLON: It seems like all three of the networks that the panel described this morning are regional, interstate and even national operations. Are there any state legal or regulatory barriers that remain in terms of wider scale in prescribing, or have you more or less dealt with those, and there are no further ones to bring to the panel's attention?
DR. WHITTEMORE: I will take that one, because I am spending and have spent probably the last half a year working on this.
The practice of prescribing and dispensing medications is regulated primarily at the state level, with the exception obviously of controlled substances, which are governed by the
Drug Enforcement Administration. Early on in the life of our organization, we took a cursory look at the regulations at the state level, and our conclusion was that it appeared at that time that electronic prescribing was allowed in the various states by the regulations.
We got to the implementation stage, and actually got to the point where we were rolling that out, and we found that we probably didn't ask the right question at the beginning. What you really have to take a look at when you look at these regulations, is electronic prescribing permitted, the way that you do it.
That is what has taken our organization close to a year to work through with the various states. You run into situations where the regulations just don't recognize electronic prescribing as a legitimate way of transmitting a prescription. Some of the regulations have been in existence, as Jack said, this is going back six or seven or eight years. The boards of pharmacy, they had regulations back then regulating something that they didn't really understand yet, and so many times the regulations don't fit the technology.
There is an issue that we run into with some regularity with respect to electronic versus digital signatures that has to be cleared up, depending on what the regulations say in a state. So there are a number of remaining issues. In specific, there is language that we find quite a lot around the states. I'll paraphrase it, but it usually runs something to the effect that an electronic prescribing must be transmitted to the pharmacy of the patient's choice, with no intervening third party entity having access to the prescription, and then they all embellish on exactly how they say that. Depending on who is doing the interpretation and looking at that dictates whether you can operate in that state or not.
So we have spent a lot of time. As an organization we basically have cleared our process in 31 states now. We have got about another ten in process. But it has taken a long time. It is again very organization specific. So I think there is an impediment that the committee needs to look at here.
The good part of the story is that the National Association of Boards of Pharmacy, who I believe you are probably going to hear from at your next meeting, have changed their thinking a little bit in terms of the role electronic prescribing can play in terms of patient safety. They now as an organization are advocates of eliminating handwritten prescriptions. I believe you will be hearing from them and their efforts to change the regulations. So basically what would happen is, they would come up with changes to their Model Pharmacy Practice Act, which would disseminate out among the states.
DR. COHN: As the Chair, I am going to take the prerogative to wrap up at this point on the session. I want to thank our presenters. It has been a fascinating and hopeful session for all of the members of the subcommittee and staff.
I am reminded that this is an area that is in the crosshairs or nexus between a lot of the different standards activities and a lot of other emerging pieces. We obviously as a subcommittee need to do what we can to create simplicity and clarity in this area. Many of you have been moving forward and making decisions based on what you had to deal with at the time, but hopefully we can provide some guidance for you, we hope, in the near future.
So anyway, thank you very much. We will take a break for 15 minutes and come back at 11:30.
(Brief recess.)
DR. COHN: We are pleased to welcome Doug Bell. He will be speaking about a study that you have done and some of the recommendations from it. So thank you for joining us.
DR. BELL: Thank you. I would like to thank the subcommittee for inviting me here to summarize work we have done at Rand to develop recommendations for electronic prescribing systems. The main result of this work is the actual recommendation that resulted from an expert panel process we conducted. But I am also going to show you some preliminary results from a field study that we have done to look at what is going on among commercially available e-prescribing systems in comparison with the recommendations.
Just to tell you a little bit more about me before I start, I am a practicing internist and faculty member at UCLA in general medicine, in addition to being at Rand. I have a Ph.D in health services research and I also have training in medical informatics.
Why did we undertake this project to create e-prescribing recommendations? We conceived this about three years ago when we saw the explosion of new products coming into the marketplace, e-prescribing products. That was creating a situation that we still have, where there were a lot of different options available for electronic prescribing.
The systems fulfill a variety of laudable aims, like improving work flow in the office and increasing formulary adherence. But our goal was to make sure the patients' interests were represented in the e-prescribing systems. In general terms, we saw patients' interests of course being patient safety, meaning reducing medication errors, and in a broader sense, health outcomes which would mean getting the right medications when a patient needs particular medications, then also helping patients manage their costs. We were especially sensitive to that, because a few studies at Rand which have just come out in the last few months have shown that patients are especially sensitive to cost changes. Often they don't have a chance to negotiate decisions that they are making based on costs to their providers. So as the prior speakers have said, patients get to the pharmacy, they are surprised by the costs and often fail to take medications that they really need.
So with these goals, we set out to create recommendations for e-prescribing. We were fortunate to have funding from Pfizer to do this study.
Again, the specific objectives of the study were to create recommendations for electronic prescribing, to promote patients' best interests, which I just summarized, including safety, health and cost management, and also that don't hinder e-prescribing adoption or violate patient privacy, and that are supported by a rigorous objective multidisciplinary process. So that was the first main objective. Also, we wanted to assess how often commercial electronic prescribing systems are already implementing the recommendations that the panel was going to come up with.
The methods were, first we did a literature review, and that produced a summary of evidence. We fed that into a delphi expert panel process. That produced the set of recommendations, which were published today actually as a web exclusive in Health Affairs. I believe everybody has that document. Then we conducted a field study which has produced an assessment of current systems in comparison with the recommendations.
Here are the results of the literature review. This slide summarizes our results. First, notice that we didn't treat electronic prescribing as a black box, which a lot of evaluation studies might. We wanted to look at the specific features of electronic prescribing and look at what effects might be anticipated from those specific features.
We published the results of the literature review in a paper in Journal of the American Medical Informatics Association this year. I wanted that to go out to the panel, but I'm not sure it actually has. But we will try to make sure that that gets to everybody.
I don't want to spend time going through each individual finding that we had here, but suffice it to say that the effects we found varied quite a bit from quite small effects to some quite large effects. But overall, the literature was weak. There were lots of potentially important features for which there was no evidence, and even the evidence that do