This Transcript is Unedited
Room 705A
Hubert H. Humphrey Building
200 Independence Avenue, SW
Washington, D.C. 20201
AGENDA ITEM: Call to Order, Welcome and Introductions – DR. COHN, Chair
DR. COHN: Okay. Good morning. Good morning, everyone. I want to call this meeting to order.
This is the second day of three days of meetings of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics. The Committee is the main public advisory body to the U.S. Department of Health and Human Services on national health information policy.
I'm Simon Cohn, a physician, and Chairman of the subcommittee. I'm the Associate Executive Director for Health Information Policy for Kaiser Permanente.
I want to welcome fellow subcommittee members, HHS staff, and others here in person, and I also want to welcome those listening in on the Internet. I do want to remind everyone, as always, to speak clearly and into the microphone, and I think our speakers will discover that we will be constantly reminding you to get very close to the microphone because of how all these work.
Today, we continue our hearings on e-signature standards with a focus, of course, on its relationship to
e-prescribing. 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.
This morning, we begin with an information systems vendor perspective on e-signature, and this will be followed after I think the morning break by plan and PBM perspective; after lunch, we hear from pharmacies, followed by standards development organizations, and then have an open microphone and discussion by the subcommittee on I think what we're hearing as well as next steps.
As always, I want to thank Jeff Blair, our Vice Chair, for his help moving the work plan forward, and of course Maria Friedman, who has been critical in terms of us putting together these three days of hearings, so thank you both very much.
I do want to emphasize that this is an open session, and those in attendance are welcome to make brief remarks or ask questions on issues pertinent to the topics we're discussing. I would ask, just because I only have eyes in the front of my head, that if you do want to have questions or comments, that you need to come up into my visual field and raise your hand or otherwise indicate, so you can participate.
Finally, for those on the Internet, we do welcome email and letter comments on any of the issues coming before the subcommittee.
Tomorrow morning, which also will start at 8:30 in the morning, will basically be devoted to discussion about HIPAA and a HIPAA update. We'll be meeting with industry work groups and hearing updates on work going on to improve the e-prescribing standards. And of course with that point we'll also be talking about plans for January and future hearings, tomorrow morning. We do plan to be adjourned by 12:30 tomorrow.
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 conflicts of interest related to any of the issues coming before us today, would you please so publicly indicate during your introduction? With that, Maria?
[Introductions. No conflicts of interest cited.]
DR. COHN: Well, thank you all for joining us. I think we'll now move to our first panel. I understand, Michael, you are leading off the presentations --
MR. BURGER: Yes.
DR. COHN: -- and will be followed by, I guess, Jim, and then Peter, right? Great. Okay, please.
AGENDA ITEM: Presentation – E-Signature: The Vendors' Perspective – MR. BURGER
MR. BURGER: Good morning, everyone. Mr. Chairman, members of the Committee, thank you very much for the opportunity to make this presentation today. WebMD appreciates the opportunity.
My name is Mike Burger. I'm the Product Manager for electronic prescribing for the Practice Services Division of WebMD. In my job as Product Manager, I have a couple responsibilities. One of them is overall for the way our electronic prescribing products work and their content, as well as the implementation and training of those products out in the marketplace. I also serve as the Liaison for State Regulatory Affairs from the Practice Services Division to our corporate attorneys, and we do spend a lot of time on many of the issues that were talked about yesterday in the vicinity of regulatory affairs and varying regulations.
Since WebMD hasn't participated so far, or the Practice Services part anyhow, I thought it might be a good opportunity to let you know a little bit about who we are and what it is that we do.
WebMD is a pretty common marketplace name; most people know who WebMD is. And there's really three parts of it. One of our divisions is called WebMD Health, which is the webMD.com that you've seen on TV and it's a very widely used consumer-oriented health care site. We also have Medscape, which is primarily physician-oriented information and content. We also have another division which is called Business Services, and that's our transaction processing unit formerly known as Envoy, very, very widely used in the pharmacy switching business as well as the claims and eligibility business as well as physician-to-pharmacy EDI.
And last, but certainly not least, is the part of the company that I'm involved with, Practice Services, and that division primarily is involved in physician facing software that is used in doctors' offices, so what we refer to as a PAMA system for billing and scheduling, accounts receivable management, as well a full EMR. And that's the part of the company which I represent.
In terms of Practice Services, we've offered an electronic prescribing product since '95, so we've got an extensive track record in providing a product that physicians will use. It's dramatically taken off in recent years after a very, very slow start.
We have a couple of different e-prescribing applications; some are PC-based, some are PDA, or hand-held computer-based. We also have Web applications. They're either embedded within the full EMR or available as a stand alone product if the doctor just wants to do e-prescribing.
We have active e-prescribers in 39 states. Our primary pharmacy connectivity is provided by ProxyMed, and we're an active participant and supporter of NCPDP in their efforts towards standardization, and we're also participating in just about every other standards organization that there is out there in some facet within WebMD.
To give you an idea of the size and scope, our physicians that are doing e-prescribing create 182,000 electronic prescriptions in a month. As that breaks down, 83 percent of those are new prescriptions -- so the bulk of our physicians are doing new prescriptions -- and 62 percent of those are delivered to the pharmacy via fax; 38 percent are delivered via EDI.
On the refills, we have 31,000 of those transactions, or 17 percent, which are refill transactions initiated by a pharmacy, responded to by the physician. That's 100 percent electronic.
In practice, for the EDI transactions, we have very few issues with electronic signature. Those states that have embraced regulations allowing EDI have also come to the correct understanding in terms of electronic signature and we've really had few issues. Our primary issues on electronic signature really pertain to the faxes, and there's some details that I'll come to.
I spent some time last night redoing what I wanted to talk about, primarily because my initial thoughts were pretty much what everybody said yesterday; you don't need to hear a rerun. So I thought that it would be helpful for you to understand what our experience has been, because we're doing this, we have physicians that are using this technology.
What we know, for example, is that electronic prescribing really deals with two different constituencies, if you will. Physicians are all about new prescriptions. They're interested in writing prescriptions. In the exam room at the point of care, physicians typically will gravitate toward a PDA or a tablet PC. Physicians seldom are interested in dealing with refill transactions.
As a consumer, that's a problem – bothers me – but in the real world, it's primarily nurses and physician assistants that are dealing with refills from pharmacies and authorizing them. And because of that, the refills are primarily targeted towards the other staff in the office – the nurses and the physician assistants. They tend to gravitate toward a desktop PC-based application because typically they're sitting at a desk, they're not moving around.
And so what we've learned is that it's really two different things, and to accomplish the goals of physician safety, primarily the physicians are involved with that because they're the ones that are initiating those prescriptions. And that's really where our strongest hand is, because most of our physicians are doing new prescriptions. Fewer are dealing with refills.
We know that physicians won't adopt technology that adds requirements that don't exist for paper. If we require that physicians jump through hoops and use fingerprint technology and have to log in four times to do e-prescribing, they're not going to do it. We're competing with scribbling something down on a piece of paper and handing it to the patient.
Today, it's not really so much a question of which application will be used; it's more of a decision whether they're going to use an application or just continue to hand-write.
We also know that physicians won't adopt technology if it doesn't address all of their patients. So we need to be cognizant of the fact that if we have an application that's in place, the doctor has to use it for everybody, just not for one insurance coverage group of patients or another.
Another thing that we know is that they have to be able to use this application to connect with any pharmacy. If the physician has to remember – oh, this pharmacy I can send electronically, but this pharmacy I can't, they're not going to use it because the lowest common denominator is still writing it down, which is still universally accepted.
Clearly, EDI delivery of prescriptions is the way to go. That's what the industry wants, that's what we want. But, the industry as a whole is not there yet. Because of that level of technology at pharmacies, fax delivery is still necessary today, as evidenced by the volume of prescriptions that we're sending that way.
Faxes still accomplish a higher level of patient safety because they're more legible and because they reduce the transcription errors that are possible because you're operating from a typewritten document. It loses the efficiency that the pharmacy would gain of having the data come directly into their system, but it still has a dramatic impact on patient safety. So for now, it's almost a necessary evil, from where we sit.
In terms of electronic signature, we have adopted the position of ESIGN and/or UETA, and we talked about this at length yesterday. This is our definition of an electronic signature: An electronic sound, symbol, or process attached to the record.
Within our products, this is how we authenticate the prescriber's signature, so both the practice and the prescriber need to be enrolled at WebMD, so we need to know who they are.
We give them – or actually they assign locally a user ID and a password for the e-prescribing software, so they need to log in in order to have access to the product itself.
WebMD assigns that practice and that physician a log in that gives them access to our EDI network, so it's another point of control.
We credential all the prescribers when we enroll them. We make sure that they are legally allowed to prescribe and that their license hasn't been revoked and that their address and phone number and all that information matches what's in the DEA records.
Also, because we use a value added network, the value added network, the value added network also credentials those same providers, just to make sure that we didn't make any mistakes or omissions.
And the pharmacies are also credentialed, and they need to be enrolled both on our site as well as our value added network and we use the NCPDP number.
We designate the prescriber's electronic signature by this list of indicia. On Page 9 of the handout is actually a picture – unfortunately, I can't slip back and forth, but there's a picture that looks like this which points out all the indicia.
So we assign a unique serial number as well as the source system, in other words, the computer system that had generated the prescription; a date and time stamp; an identifier for the sending system; the prescriber's name; DEA number; an internal sender ID number; the name of the agent, if that's applicable – if it's not the physician, if it's a medical assistant that's writing the script; the destination pharmacy, including name, address and phone number; and the destination pharmacy's internal receiver number.
So here's that picture that I referred to, and I've kind of marked off Sections 1, 2 and 3 so that you can get an idea of what the pharmacist could look for.
And we have a pretty simple rule: If the transaction is received at the network and any of this information doesn't match, we reject it, because that, we think, is an unsigned prescription, and we send it back to the submitter and say, something is wrong; we don't know who you are, or you're not enrolled on our network.
This has proven 180,000 times last month to work pretty well. We seldom have issues with people trying to submit prescriptions where they're not authorized. When we do run into a question, it's virtually always because it's a new doctor that just hasn't gone all the way through the enrollment process. We have a pretty good system of checks and balances to make sure that everything is working as it should.
Our experience, of the states that allow EDI or fax, most don't anticipate an EDI transaction delivered via fax. You have to remember, from our system, every prescription leaves the system in NCPDP format and SCRIPT standard, and it arrives at our network that way. From there, we need to make delivery of that prescription to the pharmacy in whatever mechanism that pharmacy can accept it. And if a pharmacy is not yet EDI enabled, because there's a market need to deliver that prescription somehow, we need to turn that prescription which we received via EDI into an E-fax – we refer to it as an E-fax.
And that's where we get into some questions about how the pharmacy identifies what an electronic signature is. Of those states that allow electronic signature, only nine have specific statutes and regulations which reference electronic signature. Of the nine, only three of those definitions match the UETA/ESIGN definition.
Now, you'll notice that there are varying counts. Medco had a different number than did NABP, as we do, in terms of the number of states which allow EDI and don't allow EDI. That sort of goes to that tremendous issue that we have of interpretation of the regulations, because there's an awful lot of gray areas. And there isn't really a consistent source of information that everybody can agree to.
And that's a challenge for us as a vendor because it causes us to employ attorneys, and people like myself spend time understanding what the rules are as they change.
Another issue that we have is that the signature and the EDI rules vary for the various types of controlled substances from state to states. In some states, a counter signature is required for a mid-level provider to be able to prescribe a Schedule III or IV or V medication. In some states, it's not required.
So that necessitates us keeping track of all 50 states, plus DC, to try and understand what the rules are so that we can program our system to do the right thing. And that is a significant challenge for us.
We come to recommendations. It would help us if we had standardization of signature requirements for all prescriptions. So, whatever the rules are for Schedules II, IIIs and IVs and Vs should be the same for every prescription. And that way we need to deal with all of those issues once, as opposed to maybe 50 different times.
It would help us to have the standardization of the indicia required to validate a true electronic signature. We came up with a list and we publicized that list to the Boards of Pharmacy so that they'll understand, and the pharmacist will understand, how they know that it's a legitimate electronic signature from our system. But the way our colleagues will do it is going to be different. So it would help if there was standardization there.
It would also help us if there was recognition of ESIGN or UETA defined electronic signature for all prescriptions.
It would also help then to recognize an EDI- delivered fax prescription as an EDI transaction, therefore making an electronic signature valid.
And lastly, it would help if there were some guidelines for value added networks. We still deal with situations from state to state where there are anti-depot regulations, for lack of a better term. Those are all well-intended but effectively prevent EDI from happening in those states, and I'll show you an example of that, the specific language that's this year's, and we still have that challenge.
So it would help us in those guidelines of we were to make the guidelines for value added networks in line with HIPAA so that the data is considered protected information, and therefore even if a value added network has to manipulate the data such that it will work with the pharmacy systems, the data remains confidential. I think that that would be an appropriate safeguard and it would help us to combat these anti-depot rules.
Also, in that guideline, it would help to understand the records retention issue. If you provide the industry with a guideline as to how long that information should be kept for audit purposes, it's easy for everybody to comply. It's incredibly more complex if we have to guess at it because chances are we're going to guess wrong and we could run into a problem there.
To me, the quote of the day from yesterday was Mr. Reynolds's "viable versus hysterical." We believe that a PKI digital signature would be very costly to implement and it definitely would be an impediment to adoption. Physicians are pushing back at costs today, so if we add even a small incremental cost, that's going to be a challenge to adoption, and as Kepa pointed out brilliantly yesterday, this is difficult stuff. It's not easy to implement and it's not easy to maintain, and the industry has done a pretty good job so far of building something that works.
And when you consider that right now in the paper environment, an orally transmitted prescription, also known as a phone-in, is legal in all 50 states. And I can tell you that I could phone in a prescription to any pharmacy in the country, as long as I'm not asking for a controlled substance, because I know what to say and I know how to say it, and as long as it sounds legitimate to the pharmacist, they're going to fill it without question. So by providing an electronic mechanism which is auditable and traceable, it's far safer than an audible prescription that's phoned in.
We also can't forget that it's always the pharmacist's right and obligation to validate the authenticity of a prescription, so there is that human factor. The last point of contact before the medication leaves the shelf is a human being evaluates it and they say, something isn't right. And if they receive a prescription whether it's via fax over the phone or a paper prescription, if they suddenly get 10 prescriptions for the same patient in the same day, something isn't right and they're going to validate it and they're going to make sure that it's all legitimate.
And the same thing applies for an electronic prescription. If something doesn't seem right, it's the pharmacist that's going to be the final say. And they're licensed health care professionals, they've got a license on the line, and that's an important safeguard that we need to consider.
Somewhat off the subject of electronic signature and really my last point is on those state regulatory issues, and I think that the Committee can play an important part in helping to clarify this, exactly how EDI technology works and the necessity of value added networks in the marketplace.
This is the language from a law that was passed in Georgia this year, so Georgia, correctly so, passed regulations which allow EDI in the state of Georgia, but then, two paragraphs from that, they said that for an electronic prescription, it can't be "compromised by interventions, control, change, altering, manipulation, or accessing patient record information by any other person or party in any manner whatsoever."
So they said, sure, you can do EDI, but that requires you to maintain a direct connection from your system to every single pharmacy in the state, which logistically is never going to happen.
So we have then gone back and proposed a modification to this legislation which will allow, with certain rules, value added networks to participate. The problem is that it'll take a year between the time that the original regulations were passed. And hundreds of physicians called us and say, let's do e-prescribing, and we say, well, there's a little problem with those rules. And now it'll truly be a year before we're ready to offer this, assuming that the regulations which we have proposed are passed in January.
So if there were guidelines for the states to follow, I think that they would probably take advantage of that, because really we're having to go down the same road in each and every state that we participate with. And that's a challenge in terms of adoption, from where we sit.
And that brings me to the end of my presentation. Here's some information which is on the last page. I'm glad to help, if there's any questions following the next group.
DR. COHN: Okay, Michael, thank you very much. And is it a joint presentation, is that correct?
AGENDA ITEM: Presentation – E-Signature: The Vendors' Perspective – MR. CHEN
MR. CHEN: Well, Dr. Kaufman is the Chief Medical Officer, also Informatics. So I asked him to participate with me in case there are questions on the clinical side requires a further explanation, he can help. I will do the primary presentation.
DR. COHN: Please.
MR. CHEN: Good morning, Mr. Chairman, and members of Subcommittee. My name is Jim Chen. I'm the CEO of DrFirst. With me is Peter Kaufman, as I have said. He has testified before this Committee in the spring.
DrFirst is a vendor in the e-prescribing area. We are the winner of the TEPR award this year. And as Michael just said, in the e-prescribing arena, we think we are one of the largest vendors. We are about just a little bit fewer transactions per month than WebMD today.
We are pleased to provide this testimony on the subject of standards for electronic signature in response to the invitation of NCVHS Subcommittee on Standards and Security.
Prior to my founding DrFirst, I worked in the field of internet security and pioneered virtual private networks, VPN. I hold six patents in that area. Also, as a result of my current position, I continue to place interest in the development of Internet security.
Today, my presentation will be somewhat different from the angle that Michael took. By the way, I do agree with a lot of things you said; it's going to be very helpful to the industry. So I'm going to be focusing more on the methodology in so far as e-signature.
We believe that the subject discussed this morning translates across all the electronic health care transactions, and it's not limited to e-prescribing.
We intended to stress three points this morning – the cost and complexity of PKI. Even though I know much was discussed yesterday, it has yet to be proven effective enough to recommend for e-health care, especially as sole standard for the electronic signature.
The second point would be on the use of the unique user ID/password combination with secondary passwords such as PIN that meets the requirements for electronic signature. We also recommend allowing various existing and emerging signature technologies.
The third point, biometric validation, while it is attractive, it's not yet accurate enough, affordable enough, or prevalent enough to recommend for electronic signature.
We also call for a national recognized database, a so-called "master list" of physicians, or providers, to be developed and endorsed. I understand this effort has been taken a couple times previously; it has not really shown the acceptance or success there.
For electronic signature methodology to be successful, it must satisfy the core tenets of integrity, security, and non-repudiation while providing for the delivery of health care at an affordable cost.
The following three methodologies are commonly recommended for electronic signature standards. They should be evaluated for their ability to provide without introducing excess cost. Those things are PKI, biometrics and the user ID/password/PIN.
PKI's strength lies in its ability, depending on implementation method, to meet the requirements of integrity, security, and non-repudiation. However, although PKI has been recommended by some organizations as the most appropriate standard for e-signature, we believe that it fails the cost-effective test.
PKI, as it has been envisioned for health care, requires a certification authority to issue, update, expire, and revoke the certificates associated with PKI systems. Even an efficient, centralized implementation of certification authority, there remains a high cost associated with this new layer of infrastructure. Interaction with a certification authority also introduces increased complexity into an electronic process such as e-prescribing is attempting to decrease complexity for providers.
Legacy systems have not been built for PKI. Many health care systems are not Web-enabled or XML-savvy. Often they cannot by themselves validate a digital signature. Moving to a PKI infrastructure will mean that many providers will find it difficult to participate in e-health care without upgrading systems, a significant expense in both dollars and time.
An additional concern regarding PKI is the push to implement it at the individual user level. It is unclear whether this can be managed cost effectively. We discussed this question with Dr. Tom Sullivan, the immediate Past President of the Massachusetts Medical Society. He's also principal in the AMA's attempt at a universal, secure physician identifier.
He said: "The AMA and it's partner – and it is on its second partner – have tried for several years to deploy PKI, and because of the complexity of maintaining the certificate and developing a successful business case, have not so far succeeded. The real problem was the complexity of maintaining the certificate – the revocation, the expiration, the re-registration. The users weren't willing to pay anything, but though it should be free."
PKI remains unproven in terms of its ability to support a very high volume, real time, clinical transaction network. E-prescribing, for instance, requires a methodology able to support the real time processing of billions of transactions flowing between over 50,000 pharmacies, more than 400,000 prescribers, and many payers. To date, we are not aware of successful PKI implementations similar to those that have been recommended for e-health care.
There has also been discussion of a federated ID manager – each enterprise does their own ID access management within the enterprise –but when they collaborate with other entities, they exchange information about their validation for the user, or attributes of the user, through a standard protocol such as Security Assertion Markup Language (SAML).
By introducing additional layers of cost structure and complexity into health care systems, PKI will by its very nature slow the speed of adoption. At this point, we cannot recommend it as the sole standard for electronic signature.
Unlike PKI, it is less clear that biometrics can meet the basic tenets of a security methodology. Its relative strength is very dependent on technology involved, and like PKI, it introduces additional costs into health care delivery.
Affordable, accurate biometrics authentication continues to elude the health care industry. Although devices with biometric readers, general fingerprint scanners, are becoming more common. Complaints abound regarding both the ease of fooling these readers – false positives, a security issue – and the frequent misreading of authorized users – false negatives, which will frustrate users. Adding a level of uncertainty to existing workflows is not the most effective path to universal adoption of an electronic signature technology.
Implementing biometric electronic signatures also generally requires the purchase of specialized equipment for all users. Unless these expenses are reimbursed, biometrics will become another unfounded mandate for providers.
DrFirst believes that biometric technology has promise but will only recommend the use of biometric authenticators when devices are affordable, accurate, and common.
Today, in the e-prescribing arena, all participants are connected through a secure, encrypted network which is accessed by users via individual user ID and passwords. In the DrFirst system, an additional password, or PIN, is required in order to actually transmit a prescription. Like WebMD, we credential all users.
When combined with appropriate management processes, this system satisfies both the security tenets and the cost effectiveness tests and meets HIPAA guidelines for security. We do the internal service side private key/public key, signing and sealing, and then recording for all different purposes. So that's why we feel that it does meet the security tenets very strongly.
Of particular note, legacy systems do not require upgrades in order to participate in e-health care using the user ID password and PIN. The electronic signature method is a standard industry practice and is well accepted by providers today.
In the drive towards adoption of e-health care, this UPP, the user ID/password and PIN method, is the shortest, the most cost effective route.
Finally, in our recommendations, we have at last our recommendations here. Understand a lot of people made recommendations, but this is dear to our hearts.
The electronic signature standard must drive rapid adoption, meet the basic tenets of security, and not impeding progress by raising costs for participants. It must also meet the test of being a better alternative than the current paper and pen method, a much better alternative.
At DrFirst, we believe that the unique user ID/password/PIN method meets the requirements for electronic signature, but we recommend that the Committee adopt language that is broad enough in scope to encompass existing standards while leaving room for the introduction of new technologies when they mature sufficiently to merit implementation.
In addition, we would like to note that the lack of a nationally recognized database of credentialed physician identifiers has and will continue to hinder the ability of technology providers to offer universal solutions in the electronic signature arena. Although physician identifier databases exist, such as DEA, CMS, AMA, none has been deemed a national standard and made available to e-health care developers, not just vendors. We recommend that development or endorsement of such database be considered an important part of establishing electronic signature guidelines.
Thank you for giving us this opportunity to share with you our practical sense to electronic signature approach and to assist you in accelerating electronic health care adoption. We truly appreciate your hard work in making this a legacy we can all be proud of. Thank you.
Questions, Answers and Comments
DR. COHN: Okay. Well, thank you all for very interesting testimony. I think maybe I'll start out with a question, and I'm sure then we'll have – I can see Steve and Harry have some additional questions.
You know, we've all had a chance, I think, to sleep on our testimony last night, and the testimony I'm hearing from all of you is not – as you've all commented – is not so different than we heard yesterday.
I'm struggling with a set of issues, and I thought I'd ask you all for your comments on all of this. Obviously, right now we're talking about e-prescribing, but I think one of the charges of the subcommittee and the full Committee is to also look forward as we move towards a more integrated, national health information network, as we move towards an electronic national health information infrastructure, electronic medical records and all of that. And indeed, this is sort of the wedge in some ways moving us forward on all of this.
Now, I sort of hear arguments about technology not being ready, security – I mean, this is e-prescribing, this isn't the full suite – and yet in the next couple of years we're going to be moving into an area where we're going to be seeing much more of the full suite, and I think it's going to be very hard as we move into sort of these more robust applications -- and you may disagree with me, so correct me if I'm wrong, or help me with this one – that it's going to be very hard if we have a complete electronic medical record on line for us to be talking about, well, the very basic, I mean, not very strong level of security in electronic signature.
So help me understand. I mean, first of all, do you agree that if we were to get a lot more clinical information on line, would you think that something stronger than what you're all describing would be appropriate? And how are we going to move from here to there in some sort of a reasonable fashion?
Anyway, I'm just asking all of your thoughts. I mean, you may disagree with my basic tenet and think that three or four years from now we ought to be still having sort of basic PINs that – I mean, what's been described by the OMB yesterday as sort of a very basic level of security suitable for surfing the Web as opposed to PKI or whatever. Can you all help me think through this?
DR. KAUFMAN: I think that this is more than a basic level of security suitable for surfing the Web because of the credentialing involved by the individual companies that are touching the users.
I do believe that having a centralized, or a federated centralized, system in the future is going to be an advantage for the vendors more than in terms of security in that when we get that secure certificate from whoever the certification authority is, if it's the DEA or a third party that's been given this job, that we'll be able to know that this is a credentialized user right off the bat and we won't have to go through the credentialing process.
But in terms of security, I'm not sure that it's going to add much to the security process.
One of the concerns is the certificate itself and the ability for somebody else to get access to the certificate. Doctors are notorious for being not the neatest people in the world and not always having everything right at hand. I am a practicing physician, so I feel comfortable saying that. If you'd seen my desk, you probably would be appalled.
But we can picture the impression of the security certificate is on a smart card of the physician having an extra copy or passing it around to their staff or leaving it taped to their wall so they always have access to it but anybody else can as well. If the security resides on a computer that's password protected, well, that's pretty much the same thing we're doing now – you have the password protection to unlock it. If it's a biometric security device, there the issues associated with biometrics which I do believe will get better with time.
So the issue of the certification authority, PKI certificate, is not so much that it's going to make the system more secure than it is now but it will make it easier for vendors and easier for new companies to come into the marketplace and do this.
One of the discussions we had last spring was that, gee, we've all done the heavy lifting so everybody else can, too, and my point was that the long-term goal is not to have the vendors do the heavy lifting to have it working well.
So perhaps a small scale or moderate scale, regional pilot program of PKI that would be more on a scale that's been shown to work with PKI and to prove that it can work and be more scaleable for an area such as Massachusetts or even a larger area of New England or California or some place that's using a fair amount of electronic health care now would be a reasonable decision to make, to say, gee, we think this might be useful in the long term; let's have the government fund a pilot study, look at PKI in a little bit more complex and larger scale that's been done before but not so big that we're going to end up in a morass that we can't get ourselves out of.
And also make it voluntary so that we can see if this will work, rather than saying that the security we're doing now, which is excellent security and provides as much security as the PKI probably will in real life and action, to throw this all out the window when it's working now and slow down the adoption of e-health care.
The vendors are willing to do the heavy lifting involved with credentialing the users to get the security to work and there is a PKI or PKI of sorts, very secure connections between the vendors themselves. I believe that the current technology is excellent, and let's leave the door open and test the new technology.
MR. CHEN: To some large degree, I think all vendors are using the public key/private key technology. Like I was describing earlier, we use internally, using service side to sign and seal and so that we can support audit in the future. Every transaction is locked. We use very, very good technology.
DR. KAUFMAN: Let the record show that WebMD is shaking their head "yes."
[Laughter.]
MR. CHEN: So I don't think it's a fear of technology. It's really the cost issues and the impediments I was talking about earlier in the practical sense, because our company really started five years ago in the electronic medical records. We actually are the ASP vendor for NextGen. We have worldwide license from NextGen. We know EMR very, very well and we know the importance of security and we know the importance of authentication are the biggest elements for a secure system.
So those are things I would do, and I think with this current way of practice of security we can make this kind of medical system work for us, but with an eye for improvement. Like I said, public key/private key architecture should be looked at, not exclude it, from what is the Committee's recommendation.
DR. COHN: Okay. Michael, did you have a comment?
MR. BURGER: One thing to remember in the conversation is that when you talk about e-prescribing alone, it is very close to an interactive transaction, and all of this encrypting and decrypting when data is moving in high volume across the networks takes time and adds overhead. And that's a significant issue in the transaction part of this.
Moving all electronic medical records from point to point is going to be far less volume and it certainly doesn't need to be interactive. So to a large extent we're taking a wait and see approach. Pretty much as with any technology vendor, we can do whatever is necessary, and it's a matter really of the business case from the consumer which is either going to be the patient or the physician as to whether the cost and the hoops that you need to jump through are worth the safety that it brings, because in the end, really that's all that matters.
And if consumers decide that there's no way, given the current infrastructure, that they're interested in having their health records communicated between physicians or stored in a central repository, then that means that the security needs to be at a higher level, and if that's what's required, then that's what we'll end up doing. It's difficult to say. We're comfortable, as my colleagues, that what is happening today is safe enough.
DR. COHN: Okay. Well, thank you. I think Steve is next, and then Harry, Jeff and Judy.
DR. STEINDEL: I'd like to look at the question of non-repudiation. You listed it as one of the key tenets for the system, and then went ahead and described, all three of you, and what we've heard yesterday, is systems that I would describe as slightly above what we're presently dealing with the paper world in terms of security of identifying the user.
Again, like yesterday with the faxing the e-prescribing and the clerk signing it, in your case just picking up the phone and calling, is an acceptable signature. This indicates the level of security that we have now with present prescriptions.
But how do the systems that you're describing, the password systems, deal with the issue of non-repudiation, and is the question of non-repudiation, as Jeff mentioned yesterday, something we really should put high on our list of things to worry about?
MR. CHEN: That's the biggest challenge in what I call the unique user ID and password. Non-repudiation can be probably best implemented with public key/private key technology.
Having said that, you could to better than just simply encryption in a system to protect records for future dispute on whether or not this person actually wrote or not.
The way we, as vendor, implement that part is – I work with people in WITI – Tom Hanks is one person I'm very close to at WITI – on this subject before when we were trying to design this non-repudiation portion.
What we're trying to do is make sure that we fully authenticate a user as well as we can; then we log that piece of transaction into the system in the area where no one else can get to, even the programmer. This way we can try to keep that away from people so that, as described earlier, we use PKI type of technology, so we take advantage of PKI technology in that sense so that we're able to demonstrate that the record, once it's created in our system, is tamper-proof, and using the strong authentication as a method to make sure it was the person who did it.
Like I said, we have PIN on top of password. Certainly, you can keep both password and PIN to someone else to impersonate you, but it really is a combination of various technologies to try to meet non-repudiation.
DR. KAUFMAN: And it's a role-based system. We allow the users to enter other staff members and other physicians into the system very easily so that everybody has their own user name and password so you don't need to share the user name and password to give somebody access to the system. So we are audit trailing every touch of the system and every user and who did what, who wrote it, who signed it, who sent it is all tracked by role.
Perhaps there should be some punishment for sharing user names and passwords in terms of medical records. It's a discussion that I had with Rick Peters, a consultant for the AFP, a couple days, when we were trying to decide how serious the punishment should be. But really, with PKI, a true user level certification authority, PKI could also share the user name and password and get into that system. It really is a matter of how willing people are to protect what needs to be protected and then for the system for audit trail everybody who's doing anything and what they're doing.
MR. BURGER: We encounter this question fairly frequently, and it's interesting to me how often a physician comes to me and says, well, how can you tell if it was me that was at the keyboard if everybody in the practice is using the same password?
[Laughter.]
MR. BURGER: Well, duh! I mean, it's a liability issue, really, and we equate our electronic prescribing products to a prescription pad, and as a physician, you're comfortable from a legal and a liability perspective, about leaving a blank prescription pad in the waiting room, with a pen –
[Laughter.]
MR. BURGER: -- no problem!
DR. KAUFMAN: It's a lot worse than that. I've had doctors tell me that they give their staff a prescription pad full of signed, blank prescriptions for the staff to send the prescriptions off. When they've said, well, I'm going to give my staff my PIN code, I say, well, that's just like giving your staff a signed, blank prescription pad, and they say, that's what I'm doing now.
[Laughter.]
DR. KAUFMAN: And this is not one doctor that said that they do this.
There needs to be some rule or recommendation to limit that.
MR. BURGER: And to me, the rule already exists.
If a patient is harmed, compliments of a prescription that some person wrote, it's the physician that's ultimately responsible, especially if they have their signature on it. So, I mean, there is punishment, kind of, sort of, that's available.
So technology can only take you so far, but in the end, it only works as well as the person that's at the other side of the keyboard.
DR. COHN: Sure you want to address that question?
[Laughter.]
DR. COHN: Harry, I think we'll let you go on next. I'm somewhat speechless here, but –
[Laughter.]
MR. REYNOLDS: Michael, in your testimony on your Slide 13 – Simon said we slept on everything last night and then you threw water right in my face on it, what I thought I believe – if you take the first four words of the second line, the "practitioner to a pharmacist," I think of models and I think of how it works, and if you think of where we are right now, because we're in a situation where the doctor fills out a prescription and either the patient takes it to the pharmacist, so it goes from the doctor to the pharmacist, or the doctor may fax it, which is still dumb technology, from the doctor to the pharmacist, if you look at the model that we're talking about here, regardless of whether you use PKI, you use whatever sign-ons and passwords, you're talking about it going from the doctor to a vendor, they sign on. So the vendor is validated from the doc. The pharmacist isn't, anymore. The patient isn't, anymore. The vendor is.
And then the vendor gives it to a switch, and then the switch gives it to the pharmacy. So the pharmacy is not validating it anymore. The pharmacy is not deciding this because a pharmacist can get it from 15, 20, 40 vendors coming through a switch.
So the situation that we face is then the pharmacy has to trust it, the PBM has to accept it, and so you've got a situation where we are changing that stream. And so when we talk about PKIs and sign-ons and everything else, we're not talking about the pharmacy and the doctor anymore; we're talking about the mechanism of getting it between them. And so that is a fundamentally different directness.
And that's why this wording was so interesting to me, because I would think they probably wanted to add practitioner directly to a pharmacist, is what they probably really meant here if you read into the words.
So I think when we talk about whatever we're talking about, I'm thinking about it totally differently now because it's really the vendor, or the switch, that are validating that it came from an entity and saying that it came from a physician, because there's no way the pharmacist, other than calling, can know that, based on the model.
So I put that out as a premise, and I would like to know whether or not that's what –
MR. BURGER: Well, remember that in a paper prescription which is presented to the pharmacy, there's no proof that that came from –
MR. REYNOLDS: No, please don't go back there. I understand that. No, no, we're not debating the two. I'm talking about whether the new model is saying that the validation belongs to the vendor and the switch, not the pharmacy. That's all I'm trying to understand.
MR. BURGER: A portion of the validation does belong to the intermediaries. But, frankly, that's just as much to validate the part of it that we're controlling to make sure that the person that's using our software and using our network and our partners' network are customers in good standing and are legally allowed to be using the products.
But the final step in that process to insure validity still belongs to the pharmacist. So in the end, we're the post office. We take care of delivery from Pont A to Point B and then the validity –
MR. REYNOLDS: But you set the sign-on and the PIN.
MR. BURGER: That's true.
MR. REYNOLDS: So you set the validation. And again, understand: I'm not attacking the model. I'm making sure I understand.
If the pharmacy set the sign-on and the PIN so that they knew they were validating who they were validating, that's another model, too. And then each vendor has to use it or – back to this idea of a national whatever you have, so it's --
MR. BURGER: That adds another level of logistics which isn't insurmountable, but --
MR. REYNOLDS: But if you read this wording and you read what's going on across the state, they're looking at this directly between, and that's what I think is confusing us. So, PKI – if you put in PKI, it's still not between the doctor and pharmacist; it's still between the doctor and the switch and then on to the pharmacist.
DR. KAUFMAN: If we're talking about Michael's slides, let's go back one slide where on Slide 12 he says it's the "pharmacist's right and obligation to validate authenticity" – "to validate authenticity must remain intact."
And that's true. The pharmacist is still the one authenticating. They can say the authentication coming from the switch is acceptable or they can say it's not and call the doctor's office. Or if we send a fax, we actually have a phone number for the pharmacy to call because we know it's secure between the doctor and us, but somebody with a really good page layout program could probably duplicate the fax and get it off to the pharmacy and make it look like it came from us even with the digital signature appended.
So they could actually do that, so we also give a phone number for the pharmacy to call us if they want to, just to validate that this came from us and was secure from the doctor and save the doctor some business.
But the obligation is ultimately the pharmacists to validate this from the doctor. So they can call the doctor if they're concerned and validate it. A paper prescription can be in the patient's purse for a week before it goes to the pharmacy. It didn't come from the doctor to the pharmacy; it went from the doctor to the patient to the pharmacy.
So now it's going from the doctor to the vendor to the switch to the pharmacy. It's still the pharmacist's obligation to validate if they feel it needs to be validated.
MR. REYNOLDS: Again, not disagreeing with your model. I'm trying to make sure who's got the ball. That's all I'm saying: Who's got the ball? Because most of the time, if you think of most of the time when we deal with connections when you're using digital signatures, it's one party to another; it's not through lots of other places.
DR. KAUFMAN: One thing that would make this a little more stable is to have that national list that we called for where we would know that at least we were all referring to the same, you know, Dr. Peter Kaufman, when that prescription went through, rather than having a duplicate someplace or one letter changed in the list. Having a national identifier would make it a little bit more secure. You are still dealing with a vendor and the switch.
DR. COHN: It sounds like Steve had an issue following up.
DR. STEINDEL: Yes, I have a clarification I would like to find out, and this goes to Michael, and actually it goes to the DrFirst people because they kind of picked up on it.
But when you were describing the situation that Harry presented and you talked about it, I was very comfortable with your use for identification and you want to validate that this person is entitled to use the software and the system and then entitled to pass it on to your whoever you pass it on to. That I'm very comfortable with, that concept.
But then you introduced the word that you have the responsibility to see that they're legally obligated. Does that say WebMD is assuming the legal obligation on this prescription as well? That made me very uncomfortable, because that puts a different level on this whole system.
MR. BURGER: We're not making any legal assumption at all. But what we are doing, because we're using the DEA number as a method of identifying the prescriber, we're looking that prescriber up on the DEA database to make sure that they're able to prescribe and that their license hasn't been revoked. And if it has been revoked, I guess indirectly we're taking an enforcement because we're saying, sorry, you don't have a license; you can't be part of our prescribing network.
DR. STEINDEL: But that gets to the slide that Peter was talking about a few minutes ago which I was very impressed with, that the ultimate authority rests with the pharmacist. And that's where I would look at where the really legal obligation resides.
MR. BURGER: That's where the true legal obligation, from a perspective of liability, is, with the pharmacist, because they're responsible. So we're helping and we're trying our best to keep illegitimate prescribers off of the system so that it makes the pharmacist's job that much easier.
But we certainly would never expect that they would take our word for it because we don't have a place – we're the post office. We're just going to deliver what we receive and in the end it's up to the pharmacist that has the final say.
DR. COHN: Okay. Is there follow-up on this issue?
DR. WARREN: Both of my questions are follow-ups on issues –
DR. COHN: Okay, Jeff, can you hold for a second? Okay.
DR. WARREN: The first one I have is really for you, Michael, but DrFirst, chime in, too.
On one of your slides, you said that when you looked at renewals, 100 percent of those are signed off by RNs and techs. And so now we're looking at: How do you validate that?
So are you looking at putting together some sort of technology that shows that it's a co-sign, much like we do verbal orders that are given to RNs that they then file those orders and later they're co-signed? I mean, how are you going to validate these refills, because you've also said that if you don't account for the workflow in the physician office, this stuff is not going to fly? And so we know that refills are going to be done by staff, not the original prescriber.
MR. BURGER: Actually, the testimony was that 100 percent of those refills are routed electronically, but definitely not 100 percent of them are dealt with by mid-level providers. As a matter of workflow, though –
DR. WARREN: Not mid-level providers which are – or physician assistants and nurse practitioners –
MR. BURGER: I beg your pardon.
DR. WARREN: -- which may have prescriptive authority.
MR. BURGER: Right.
DR. WARREN: I'm talking about the techs and the RNs who don't have prescriptive authority.
MR. BURGER: In the course of practice, a physician usually will assign certain responsibility for responding to pharmacy-issued refill requests, to respond to the pharmacy yes or no. Those refill requests are annotated by the user or an agent, if you will, who is responding to that request on behalf of the physician.
That information is passed back to the pharmacy when it's responded to, and that's valid, as far as the pharmacy is concerned and as far as the regulations are concerned.
DR. WARREN: Okay. Then I need to understand, too, how you define refill. Is this the refill in a prescription it says "this can be refilled three times," or is this the renewal of a prescription whose refill has expired?
MR. BURGER: It's a renewal --
DR. WARREN: Okay.
MR. BURGER: -- because it's not required, as you know, for the pharmacy to contact the physician for each additional fill on the original.
DR. WARREN: I just want to be sure I understood the way you were using the word so that I don't –
MR. BURGER: Unfortunately, they are interchangeable and can be confusing as we use them.
DR. KAUFMAN: If I could make a comment on it also. We do something very similar to what they do. We allow the physician to assign a provider agent. It's done with the physician actually filling out a form legally assigning the rights to somebody in their office to act as a provider agent and they can send prescriptions, renewal requests, just like they're doing now in the office when the pharmacy calls and the staff person says, yes, that's fine.
The one thing that we do, and I'm not sure whether WebMD does it or not, is that we require the physician to countersign all of those prescriptions with increasingly annoying alerts if they haven't done it quickly enough so that that prescription is sent off but we still want the doctor to see it, which I believe is the law for the way it's done on paper and phone right now but a lot of doctors don't do that.
DR. WARREN: Okay. So you're really using kind of a user name/password for the agent that then is countersigned, or a co-signature comes with it, which then has its own user name and password?
DR. KAUFMAN: The co-signature does not go to the pharmacy. It's stored in the system. The physician has the authority to void the prescription if they don't feel that prescription should have gone, which sends a stop message to the pharmacy and voids it into the system, but the physician is co-signing it.
The way the system is set up, the physician co-signs it before it goes. If the practice signs for a provider agent, it does not get co-signed before it goes; it's co-signed after it goes, because the workflow in a doctor's office is sacred and physicians are impatient people. At least I'm saying that they're people.
[Laughter.]
DR. KAUFMAN: And they don't want to change the workflow such that if a pharmacy calls for a renewal, if they get a renewal request electronically, whatever, that the staff has to come in, they have to log into the system, they're in the middle of seeing somebody else, to countersign this. They don't want to alter their workflow.
So a lot of physicians really strongly want to be able to do this provider agent issue, which is what they're doing now.
DR. WARREN: Okay. So the message then that's passed is really the signature of the agent, and that's all the pharmacist sees?
DR. KAUFMAN: The agent or Doctor So and So. A specific physician is assigned to that.
DR. WARREN: Okay. That's the piece that I was missing.
The second clarification that I wanted was back to this Georgia law, as everybody else has picked up on on the panel. If I think in a very broad level of technology of which paper is a technology and then we go back to Harry's comment of physician to patient, and you're absolutely, we're a paper world, there is an intermediary between the physician and the pharmacy and that's the patient who hand-carries it or the family member or the agent of that patient. So we already have an intermediary here.
So in some ways you can look at electronic e-prescribing of the services that the two of you provide is the same thing as this agent of the patient or the patient themselves in transferring that.
So help me understand how this law in Georgia is causing – I guess what I'm asking is: Has there been a ruling that this kind of transmission is different than having a patient or a patient's agent take a piece of paper from the doctor's office to the pharmacy?
MR. BURGER: The word "electronically."
DR. WARREN: And that's the key piece that's different?
MR. BURGER: The presumption is made that a consumer wouldn't be able to electronically encrypt or issue or produce a prescription, that it would have to be the physician who is doing the order.
The intent of this is to prevent a third party in between the physician and the pharmacy to alter or switch the medication to something different or to direct it to one pharmacy or another or in some way change what the doctor has prescribed. That's the intent here.
DR. WARREN: Okay. And with so many laws, the intent is not actually what is in the words and what's interpreted –
MR. BURGER: Very true.
DR. WARREN: -- later on?
DR. KAUFMAN: Can I add to the intent? Part of the intent also is to not change the language of the prescription which may be subtle between the physician and the pharmacist.
As a result of the spring meetings – I sit on three committees working on a SIG standard, and in fact I believe that Lynn is going to be testifying on that tomorrow, and I was kind of trying to get her to say something a little earlier – but one of the very powerful things coming to us from the pharmacist and NCPDP is that the language of the SIG cannot be changed to put into electronic form.
So if it doesn't shoehorn into an electronic form, you have to send it as a text string, and you don't want to alter that and then send it off to the pharmacy differently from what the doctor said.
If the doctor enters it electronically, so they're entering it in electronic form, you can send those elements along the system and then rebuild it on the other end, but if they're entering it as a text string, if you want to send it as a text string, it's important the pharmacy receives what the doctor was prescribing. Did I say that right?
So that might have been part of the intent of the Georgia law also. And since I got the microphone and people here know I like to speak, let me talk a little more about this issue, because I would go a little further than Michael did in calling for more than guidelines.
I'm currently working with at least one state, along with SureScripts, to help them find guidelines to rewrite their e-prescribing law, and they're using Massachusetts and Maryland as their models. But the boards of pharmacies who are – I mean, I've dealt with a few of them now and they've all been great – but their job is to come up with these guidelines and regulations and if they get somebody, another state's, regulations, they need to rewrite them, and they're always a little bit different because that's their job, is to do this.
I think if we got from the Federal government a set of standards for electronic prescribing in the states that would preempt the state laws, it would make life a lot easier for people like Richard Brooks and Rick Ratliff, and us, who are sending these prescriptions to the various states where the laws, even if they're subtly different, are different enough that the applications need to jump through a lot of hoops 50 different ways.
DR. WARREN: Okay. So my final – just to make sure I understand what you're telling me – that if there is
no change in this message from the physician to the pharmacy, then we're okay with electronic prescribing. But if somewhere in there there is a change in that message, then this particular paragraph applies? Okay.
MR. BURGER: This says that even if there is no change between what the physician writes and what's received at the pharmacy, if it passes through in any manner whatsoever, anything between here and there, it's illegal.
DR. WARREN: Oh, okay.
MR. REYNOLDS: That's why I said "direct." That's why I mentioned direct. They meant directly.
MR. BURGER: And so really there's the challenge. If it was in parentheses, as long as it remains in exactly the same form, then we're fine, because nobody's changing the data.
DR. WARREN: Okay. Well, that's what I thought I heard initially, and then I was looking at it. I mean, I don't know how you would do an electronic prescription without it passing through someplace.
DR. KAUFMAN: A fax transmits through a switching company at the telephone company, so that should be the same thing.
DR. COHN: Jeff?
MR. BLAIR: I want to get some additional clarification, and I'm kind of pulling from what we heard from the three networks yesterday – RXL, ProxyMed and SureScripts – and they indicated that there were three major impediments towards adopting PKI. And PKI was referred to there as a technology. And you've echoed these, but I want to drive down a little bit for some additional clarification.
One was the additional cost. The second one was the performance hit on the network to be able to perform PKI. Actually, I guess there's four of them. The other one is the certification requirement, setting up a separate entity for certifications just for this.
So the fourth one that I'd like you to comment on a little bit more was the technology function that they told us was essential in the way the world is today and maybe even the way the world would be in the future, and that is that it is necessary to open the message, or especially if the NCPDP version that comes from the prescriber is different than that that would be at a dispenser, a pharmacy, it may be necessary to open the message to do some reformatting – not change the content or the intent of the prescription but to just alter the format to accommodate the different versions of NCPDP, and that was also complicated by the fact that there might be a prescription coming from acute care institution in an HL7
format and once again you would have to make format modifications, and that that required the opening – once you open it, PKI of course would destroy the ability to do non-repudiation and the ability to be able the bond the signature to the document with the electronic signature and the combination of a hashCode.
So in short what I'm getting to I'd like your comments on that impediment. Do you share that same concern, and if – you've also wound up saying we should have pilot tests; we should include PKI in pilot tests to see if these impediments can be addressed in the future.
Well, if there are pilot tests, do you see something that should be included in those pilot tests or constructed in those pilot tests to try to address or accommodate this particular impediment of needing to open and reformat to accommodate different versions?
MR. BURGER: Well, as WebMD, we have an extraordinary amount of experience in the EDI business not only in terms of prescriptions but in terms of claims and eligibility transactions and pharmacy to PBM transactions. And throughout all of the years that we've doing this and all the experience we have, it isn't even theoretically possible for everybody, every submitter of the transaction and every receiver of the transaction, to all be on the same format. I mean, it's just not logistically possible.
And when you consider the number of physicians and individual pharmacies that would need to be connected, the sheer logistics of that – and somebody mentioned yesterday the big bang of having everybody switch and all at the same time – I mean, the logistics of that just don't even make it theoretically possible.
And, you know, we depend on third party networks primarily to do that translation for us, but even at the Practice Services division of WebMD we have that challenge because some of our products are distributed in nature, so they're running on a client server application in an individual doctor's office.
So if I have a few thousand doctors that are doing e-prescribing and the day comes for me to change them from one version to the next, I need to simultaneously be touching thousands of systems all at the same time or something is not going to work.
So on a smaller scale we have that challenge just with our own software, and others have similar issues but in a web-based application it's somewhat easier. And so you could only imagine, then, for all the different trading partners on the pharmacies, I don't think it would be possible for us to be able to operate in an environment where some translation didn't take place.
MR. CHEN: Yes, we mentioned about the pilot project. That was because we feel that at some point in the future the PKI technology and the vendors' comfort level was the cost and the ability to manage PKI type of technology become more acceptable at some point.
And because nobody really knows what that some point is, and being a technologist myself on the security side, I felt it's important for us not to exclude them for participation for the future evolvement of e-health care.
So that's why we made the recommendation that if we go further in this area, we should have a federal funded pilot project. Large-scale enough – it cannot be just a thousand physicians involved – you've got to have enough to show the transaction volume, and as Michael said, those kind of systems have to enough systems involved in order to assess the impact of changing certificates and things like that.
DR. COHN: Harry, did you have a clarification or an additional –
MR. REYNOLDS: Another question.
DR. COHN: Another question, okay. Well, I would like to ask a question before you ask a question. It's on another issue.
Yesterday – and I wanted to ask the same question today as I asked yesterday, and I think we were talking to the value added networks and I was sort of indicating that we may make recommendations about electronic signature for e-prescribing and even for the National Health Information Network, but obviously there's an area called controlled drugs and the prescribing and dispensing of controlled drugs, which is an area that really is under the authority of the DEA, and at some point the DEA may come up with whatever level of electronic signature or things that probably you know very well, unknown possibilities.
Now, the question is, from your perspective, would your life be better if there were two different levels of security related one to controlled and the other to non-controlled drugs or would you like to see whatever level be the same even if it might be a higher level of security for all dispensing? I mean, what would you like to see in the future?
DR. KAUFMAN: Frankly, I'd like to see the same level of security being the level of security that we're using now, which is quite strong and workable. I'm concerned that the DEA is going to come up with requirement for biometric authentication and PKI, in which case I'd want two levels of security so we could continue doing what we're doing now and ignore the requirement of the DEA for the level of security that they want to send at least Schedule II drugs. I don't see a good reason that Schedule III through V drugs, which can be faxed now, should require more authentication than we're currently using, which is dramatically more than paper or fax.
It frustrates me that the DEA did not attend this meeting and to hear the vendors and the backbones speak about the experience, wide experience, I mean. Our company has a lot of experience with security but nothing in terms of the transaction volume that WebMD has had to know what is and is not going to work in the real world in a doctor's office, and I would hope that the DEA would broaden their range of who they're listening to to allow a strong level of security that is currently adoptable, scaleable and usable as opposed to requiring something that we cannot provide.
Actually, I think our company probably could provide it, but I think most of the companies are going to have a great deal of difficulty dealing with this, and the inaccuracies of the biometrics, the current devices out, are going to frustrate doctors and they will not adopt.
So, personally I think that it should be the same level of security. It should be the level of security we're using now.
MR. CHEN: That's Dr. Kaufman's personal view.
[Laughter.]
DR. KAUFMAN: Uh-oh. Then we should have had you go first! It's okay.
MR. CHEN: We see this opportunity for us to share different opinions.
As you said, I do agree that if we can have one uniform approach, that would be great. If we have to have two layers, our company would be able to handle it.
I cut my teeth in the Internet security in '93 and worked with Jim Bidzos of RSA in those days. I was one of the two or three companies that RSA gave worldwide license, like Netscape. So I share in the RSA owned product of my company at the time.
Anyway, so we have the technology; we know how to do this. So our concern is: How do we make this practical?
So that's why I was saying in the practical sense of the vendor. I'm not speaking for DrFirst. I really feel like I'm speaking for e-health care. If we do not make this happen now, we're going to disappoint an entire industry as well as patients, consumers out there. We have to do it right.
So I'm speaking, and I'm sure Dr. Kaufman is saying the same thing –
DR. KAUFMAN: If it's interesting at all, I think we said the same thing.
MR. CHEN: Yes, but the thing is I don't want to second guess what DEA is doing, okay? We don't know enough about that, and I do think it's very important for all of us to come together and treat this as a legacy for us to work together. And that's all I want to say.
[Laughter.]
MR. CHEN: Not so much defense.
DR. COHN: Michael, then I may have to ask the question again, but go, please.
MR. BURGER: I mean, the truth is that we're operating under a dual standard today and the way that our software and just about every other software that's out there works is that when a Schedule II medication is ordered, the EDI function isn't available and the physician only has the ability to print the prescription and sign it or else manually fill out the required blank and give it to the patient.
And somebody asked the question yesterday about the effectiveness of those regulations in Nebraska and Wyoming. They've been incredibly effective because nobody does e-prescribing.
[Laughter.]
MR. BURGER: Yes, there's no EDI fraud because there's no EDI.
So I think that what the answer will be is should DEA come out with a PKI digital signature requirement, we as a company would need to be shown a business case for developing that capability and then pass that cost on to the user, so I expect that not much would change. They'd say for the two or three percent of the prescriptions that would require this, it's just not worth the cost, so we're just going to print those.
DR. COHN: Okay, let me just make sure that I really understand what you're all saying and it's certainly may be a conversation we have during the open microphone later on today.
Now, yesterday we heard that up to 15 percent of prescriptions were somehow under DEA purview, and obviously I have no insight into whether they're going to make a differentiation for Level II versus Level III, IV and V medications or whatever.
But what I'm hearing I think from all of you is that whatever DEA comes out with, what you would like to see potentially if your judgment was it was of too high of a level, you'd like to see a lesser level of security, something that we might all feel comfortable with with non-controlled drugs, be sort of what you would generally use and then make the determination about how you might handle that higher level. And you might, for example, decide just to print it out locally. Is that what I'm hearing?
MR. BURGER: I agree with Dr. Kaufman's comments that we're comfortable as an industry that the security that exists would work just fine for all medications. And the way that the rules work is the Schedule II medications, or the narcotics, which EDI in fax has not allowed under any circumstance, and for the other, the Schedules III, IVs and Vs, they can sometimes be sent via fax and sometimes not. Some of the state rules vary there.
So the Schedule IIs, which are really the ones that we're concerned with, are a pretty small percentage of the total prescriptions that are written.
DR. COHN: Okay. Well, I guess I maybe keep asking the question the wrong way, but I think I've heard the answer is yes, basically, to what I was asking. Okay, thank you. Harry?
MR. REYNOLDS: I'll say something a little surprising. I think HIPAA's growing on me, so –
[Laughter.]
MR. REYNOLDS: -- you're going to like this one.
If you look at this process, we have a HIPAA security rule coming out in March, and that requires covered entities to validate, assess and to validate, that they're going to take care of whatever they touch. You already have privacy. You have covered entities.
If you think of e-prescribing and you think of HIPAA, most of the HIPAA transactions, they didn't really actually have some drugs that were going to be given out or anything else; they're mostly after the fact or they're talking about eligibilities and other things.
So this goes to a new level. This is why this is so difficult. But if you took anybody involved in e-prescribing and you made them a covered entity where they have to, under the HIPAA laws, validate that they understand privacy, understand security, they're going to handle it right, they're going to do everything they need to do.
And then we put these standards that we're already putting together as part of that under the umbrella of HIPAA. You have added a degree of assurance that we're spending kazillions of dollars paying health care and everything else through where fraud could be equally as much an issue.
So you have an umbrella. The problem is that covered entities – that's one of the issues we've dealt with in some of the HIPAAs, who was the covered entity? Well, with some of these state laws, they're trying to say if you touch a prescription, because there's going to be actual drugs administered, you've got to be in the game. That may be a way, as a Committee – because our responsibility as a Committee is not really to set policy; it's to build something that can allow the industry to go forward.
And then if the DEA and the Secretary decided that they wanted to up for schedule these other schedules a level of security they wanted to add, fine, but it comes under the umbrella, and we have some jurisdiction over the umbrella.
And that is a way to consider, because that covered entity thing is where you bring everybody in at a new level. You become a covered entity. When you touch something; the game is different. I mean, you can have all kind of people all over you, you can have all kind of structures set up on you; you've got to commit that you're doing it and everybody can watch you.
And let me add one other thing. And we're also not – we're still not getting between the doctor, the patient or the pharmacy. They all have a right to say, uh-uh, that's not what a doctor ordered for me, or, no, I'm the pharmacy, I'm not comfortable with this one – it's the third patient I've seen come out of that office today wanting something like this.
And a lot of the e-prescribing has said, and all this stuff has said, don't get between the patient and the doctor – you know, having a PBM saying it's for this or that. And it's also said, don't get between the pharmacy and the doctor.
So that may be time and away, as we look at this, that allows us as a Committee to stay within a recommendation, but that's just a thought. But I would love to hear from them whether or not this covered entity thing causes you a lot of grief, because some of you are already clearinghouses and –
MR. BURGER: Right, we have those agreements in place right now, so we're already doing that. And frankly, exactly what you suggested is what we suggest in states like Georgia, to say, the intent of this is to prevent altering and diverting a drug to a different pharmacy and as a HIPAA covered transaction and as a covered entity, we can't do that. So, really, that's what you want to say instead of this.
So we agree 100 percent.
MR. REYNOLDS: You can't go what again?
MR. BURGER: To treat the prescriptions as HIPAA transactions and therefore we can't do things with the prescriptions. We're just responsible for routing them.
MR. REYNOLDS: No, you still translate them. Remember, a clearinghouse is a translator.
MR. BURGER: I understand that, but –
MR. REYNOLDS: Yesterday's testimony said that there are times we don't want people to change all their legacy systems; we want them to be able to translate. So that would still give you that authority, but again, under the umbrella of the HIPAA regulations.
MR. BURGER: We are in agreement and that would place zero additional burden on us.
DR. KAUFMAN: We are, too.
DR. COHN: Looks like the audience is raising their hand on this one.
[Laughter.}
DR. COHN: Steve, and them maybe we can wrap up after this.
DR. STEINDEL: Yes, I have a question of Harry.
[Laughter.]
MR. REYNOLDS: Should I go over there?
DR. STEINDEL: No. Who in this process is not a covered entity right now? I mean, I agree with what you're saying.
MR. REYNOLDS: Vendors are not a covered entity.
DR. STEINDEL: But they don't handle it. They produce systems –
MR. REYNOLDS: No, that is not true. They will take in the original script as selected by the doctor. And my point is, and we've had this issue in a lot of cases. The vendors have been excluded.
The clearinghouses were not, and the clearinghouse is defined as somebody that takes it in and translates it. But the vendors, the actual people – so if
I was buying WebMD system to do e-prescribing, in that case – forget that you were a clearinghouse before – they would not be covered.
DR. STEINDEL: Thank you.
MR. REYNOLDS: That's the difference.
MR. BURGER: However, in our contract, I mean, we include the language, although it's not required.
MR. REYNOLDS: I understand, but under the jurisdiction of HIPAA, you are not. You would not be covered as a covered entity under that.
DR. COHN: Well, I think the other question was – we heard yesterday there was some confusion about whether the value added networks –
DR. KAUFMAN: We are a busy associate, however.
DR. COHN: -- are covered entities.
DR. KAUFMAN: The vendors are business associates and therefore have –
MR. REYNOLDS: Yes. Well, I know, but that's a dramatically different level than up front, in the game, you got the label and you have to answer to everyone that's involved, not just your business associates.
DR. COHN: Yes. Okay? Any final questions? Shall we take a break? We're running a couple minutes early, so we'll take a break and we'll come back at 10:30.
[Break begins at 10:25 a.m.
[Meeting resumes at 10:40 a.m.]
DR. COHN: Okay. We're going to get started here, and we're happy to have Terri Swanson and Phil Rothermich joining us, talking about, I think, the plan and really PBM perspective and how this all plays out.
I think, Terri, you're going to be leading off? Is Phil going to be leading off? Okay, Phil, you're going to be leading off then, sorry. I should have noticed from the overheads here, so – thank you.
AGENDA ITEM: Presentation – E-Signature: The Plan/PBM Perspective – MR. ROTHERMICH
MR. ROTHERMICH: Thank you for the opportunity to be here this morning. We've coordinated our presentation so I'm going to go through a little bit of overview and then Terri's going to take us more on a specific, technical level the security and authentication procedures that are currently in place with an end goal of suggesting that the authentication and security procedures in place today are sufficient for the purpose that we're all here and should be adopted as standards. And we'll walk through that.
Before I begin, I just wanted to make a point in response to Dr. Cohn's question earlier about whether greater security may be necessary in connection with moving to EMR and so forth. I don't think the argument is really that the security in place today is somehow substandard.
The issue has more to do, I believe, with authentication, of making sure that we know there's a physician on the other end, and what we'll walk through today is trying to give you comfort that in fact the information that's going through the systems in place today for electronic prescribing are indeed secure, considerably more secure than what exists today in the paper environment, and is consistent with what is out there today with respect to significantly more sensitive kinds of health care information in like health care claims.
And this is really just sort of perspective, so when we're talking about the security pieces, we keep in mind what we're dealing with, just an example. We get a prescription from for an antibiotic, whether it comes electronic prescribing or whether it comes as a claim in our PBM claim system, we don't know what that antibiotic is being used for. If the physician office files a claim for the visit that generated that prescription, there's going to be a diagnosis code. They're going to go through some of the very same types of security procedures to get that claim to the insurance company that we're talking about using for e-prescribing and it's going to contain significantly more sensitive information.
So the health care claim is going to have an ICD9 code that talks about whether it's an ear infection or an STD. And the security procedures in place today are very similar to what is being used for e-prescribing, so again, just perspective.
What we're going to do today is, with this chart, we're going to walk through the specific procedures that are in place at each point in the chain with respect to e-prescribing and try and take you through why, from a security and authentication perspective, these are sufficient, and then we'll talk about where the improvements are possible.
To your point earlier, if there is additional security or authentication that could be added later, probably the most significant thing is on the front end, in other words, the security of the system exists with respect to securing the information flowing across the wires, but that security is only as good as the front end system to allow people to access it.
So what we were talking about in the last panel, somebody gives away their user name and password, it shoots the security that you've created. So, again, just to the next slide which sort of takes us to that.
I want to make a clear distinction between the concepts of security and the concept of authentication because some of the conversation around electronic signature at times tends to confuse the two and it's important in understanding the difference so that we can tackle each of them appropriately.
Security really has to do with getting a transaction sort of from here to there without interference so that we can be reasonably sure that nobody along the chain has accessed, modified or redirected what we're trying to achieve.
And this is really where PKI comes into play, where, again, the existing systems create good security; PKI arguably is a level high in security but may not solve the underlying problem if what we decide is the real problem is authentication.
Authentication has more to do with giving confidence to the pharmacist that they can rely that the person who they believe is sending the prescription is actually the person on the other end, and I've put in gray here the second piece of it, which is that the prescription could not reasonably be repudiated.
And the reason I've got that sort of highlighted is because in the context of e-prescribing, non-repudiation has become a very significant point where it really isn't a significant point in the paper world today. In other words, a physician writes a prescription, signs it, it gets to the pharmacy; the pharmacist sees a signed prescription and fills it.
If someone steals a prescription pad and fakes the physician's signature, the physician could say, I didn't sign that; that's not my prescription, repudiating the prescription, and there's no way to prove otherwise, really. I mean, you could get into signature analysis and so on and so forth.
But what we're trying to get to with electronic prescribing is a secure enough system that the only way to get a prescription from this physician to the pharmacist is with access tools that are clearly assigned to the physician so that if the prescription comes out of that system, it's difficult for the physician to say they didn't write it or authorize it.
And this where the front end security becomes more significant, because when you talk about biometric types of access points, that's when you really solve the authentication issue, but I think it's generally believed that those aren't yet available.
So, moving from there, just wanted to start with kind of an overview for security and authentication in electronic prescribing. What's out there today is really meeting the HIPAA standards with respect to security, provides reliable means of authentication and security certainly much more than existing processes.
There was a lot of conversation yesterday about the fact that the patchwork of state laws and regulations and interpretations have created a fair amount of confusion, particularly at the pharmacy and with the point of care vendors where it isn't clear what it is they have to comply with.
And there is considerable conversation about taking the security and authentication pieces for electronic prescribing far beyond what is really achievable today, certainly as you balance that against adoption and considerably farther than what is in place with paper today.
Again, there's sort of a mantra we've been pushing this year, which is "don't let perfect be the enemy of good." And I think we face that again here today.
The next slide I'm not going to spend any time on but really just speaks to the requirements for HIPAA and makes the point that electronic prescribing in the systems in place today that are providing this technology are really meeting all of the security requirements of HIPAA for protected health information.
I wanted to walk through, just for perspective, and again, we're not arguing that today's world is sufficient, but again, we're going from sort poor or reasonably poor security to very good security and want to make the point that for the 85 percent, if that's the right
number, of prescriptions that are not controlled substances, this is a significantly better system and point out the irony that to the extent there's conversation about adopting a single system that may be what DEA is focused on for controlled substances, what we could do is kill the whole thing, and it's important to understand that the security and authentication procedures for paper prescriptions are really extremely poor and it would be, I think, a tragic result to end up forcing people back to paper because we're trying to find perfect.
If you look at paper prescriptions today, the security in place is extremely minimal in that people may guard their prescription pads to some extent. The last panel, there was some conversation about people signing blanks.
Clearly, within the doctor's office, there's the potential for bad actors and even with patients and people passing through the doctor's office, presumably there are regular opportunities to get access to pads.
But there's also relatively easy ways to copy a prescription. For people to want to fake paper prescriptions, it really isn't that difficult. And when you talk about fax and phone, Mr. Burger made the point earlier if you know what you're doing, you can call a pharmacy and get a script filled relatively easily.
With respect to the wires, they're sending faxes and making phone calls across regular phone lines, so we're not talking about any sort of encryption or protection of that kind of information as it's going across the wires.
With respect to electronic prescribing, as Terri's going to speak to in depth, there are significant security procedures every step of the way. There's channel encryption, there's all kinds of access restrictions, so that it's relatively easy to get comfortable that when you're trying to get a prescription from the physician's office to a pharmacy in a secure manner, we built a system that gets us there.
I wanted to spend a minute talking about why authentication is important, and this has been sort of alluded in the last couple days so I won't spend a great deal of time on it, but it's the pharmacist's responsibility to authenticate the prescription.
And the way they do that today is really driven in large part by methods of practice that are accepted within the pharmacy world. So it isn't as if what they're doing is clearly authenticating the prescription; it's they're going through what steps are available to them.
So, for example, a fax comes from a physician's office and they validate that the header on the fax matches a fax number that's assigned to a physician's office. IT people will tell you it's extremely easy for somebody to change the header on a fax machine to show a different number than where it's coming from.
So there isn't really authentication there, but the pharmacist and some of the state laws relating to authentication specifically refer to validating the fax header as one means of authentication.
So there's methods of practice in place that most people will tell you are insufficient, but they're what the pharmacists are used to, and it's the pharmacist's license that's on the line.
So the conversation in the last panel was about whether this is really left to the pharmacist, and indeed it is. The question is giving the pharmacist confidence that the system behind the electronic prescriptions they're getting actually does authenticate the physician and give them enough confidence to rely on it and making it clear in the state in which they practice that their right to rely on that process that's in place exists, because a lot of what the problem is today is the laws don't deal with it so they're not sure what kind of authentication they're required to do.
They don't have a method of practice. And so they're concerned about putting their license on the line without knowing, and so people feel compelled to go ask.
And if they go ask, they don't go ask necessarily, can I take an electronic prescription? They ask, can I take an electronic prescription – knowing what I know about the WebMD system? Can I take an electronic prescription knowing what I know about the DrFirst system?
So it's a lot of back and forth and it's not necessarily a simple answer. Many times, to get an answer from a board of pharmacy, you have to appear before the board. So you spend time getting on agendas, you spend time lobbying the members of the board, and so on and so forth, and it's just a very, very inefficient process.
One of the points I think that's key here is the focus needs to be on substantive authentication of the person on the other end. Some of the conversation around electronic signature and some of the state laws trying to deal with electronic signature really confuse the issue because they talk about electronic signature as the answer.
The thing that electronic signature provides really is authentication. So what we need is a system where we can be confident that the person using the system is the person we think it is. And then whether you want to consider the signature an X or the physician's name printed or a symbol like Prince, it doesn't matter because we know whoever sent that prescription is the person we think it is on the other end.
And so I would encourage the Committee to think more about authentication than about e-signature or PKI because the real problem we're trying to solve is validating that the people using the system are in fact the people who we think they are and that they're in fact authorized to write prescriptions.
Similarly, we're going to do a short comparison of the authentication procedures with respect to e-prescribing versus paper. I referenced this a little bit talking about fax numbers, but again, with paper, the only thing people have to rely on is what they've always relied on.
So a pharmacy gets a prescription with a signature – there was reference made yesterday to a pharmacist recognizing a physician's signature. I don't believe that. I think pharmacists are busy, and certainly pharmacists in big cities see prescriptions from a lot of people and they don't have time to recognize signatures.
So I think we're sort of deluding ourselves if we think there is really much true authentication in place other than these sort of historic methods that pharmacists and pharmacy boards have come to rely on for lack of anything better.
But again, if you look at the way the systems are built, the way physicians are authenticated before they get access to these systems, the way the systems connect one to the other and verify the links in the chain, there is significant authentication that takes place that the pharmacist should be able to rely on.
The question is creating a national system that makes sure that those processes have taken place and gives the pharmacist the security knowing that they can rely on those processes without fear of censure.
I've got a short slide here on why PKI doesn't work and I think I'm just going to skip through it because we've had so many conversations about that. I think that point's been made, although I guess we'll just sort of formally underscore it here.
What we want to suggest is that there is a solution and we've sketched out here a three-part solution.
One is to adopt what is today the best practices as standards, and Terri's going to walk through what those standards might look like, and implement them as a minimum level for security and authentication.
The conversation yesterday about whether or not the Committee is free to adopt specific technologies I think can be resolved because the standards really can create a floor. So rather than adopting a specific technology, you can adopt a specific level of security, for example, that vendors are free to go above but not free to go below, so that you're not exactly adopting a technology as saying your system has to be at least as secure as these types of technology can provide. If others come and people choose to adopt them, that helps.
I think it's important to clarify by rule that the standards adopted indeed do supersede state laws and regulations pursuant to authority in the MMA, and I think there's been some conversation about that we don't necessarily need to get into, but both the language in the MMA allows for it, the jurisprudence around preemption certainly allows for it given what's in the rest of MMA, and the need for the industry, if we really are intending to drive electronic prescribing both from a substantive authentication and security perspective as well as driving adoption, make it required.
Finally, we'd like to suggest a certification process for vendors which may be viewed as somewhat controversial but to Mr. Reynolds's point this morning, in order to give the pharmacist the comfort of relying on a particular system, you really need some level of verifying that a given system complies with the standards we adopt.
It's kind of like you can't really have laws with no police. The question is people are, I think, hesitant to talk about certification because we're all wondering who's going to be the certifying body and whether or not there are resources to do that.
But I think it's worth noting that the networks today that are dealing with point of care vendors – RXHub, SureScripts, ProxyMed – all of them are currently engaging in processes to essentially certify the point of care vendors who are using their systems to make sure that the security procedures are indeed in place, that the authentication procedures are in place.
So if you created the standards, I think it's safe to leave to those bodies the process of certification so that once a script comes from one of these certified vendors, it's deemed valid for federal purposes and because of preemption for state purposes so that every pharmacist can rely that if it comes from one of these vendors, it's a valid prescription, they can fill it, and the fact that it came from these vendors is indeed the authentication that they're trying to get to and they can do a side with all of the conversations with boards of pharmacy and looking at fax headers and so on and so forth.
And with that, I think I'll turn it over to Terri.
AGENDA ITEM: Presentation – E-Signature: The Plan/PBM Perspective – MS. SWANSON
MS. SWANSON: Thanks, Phil. Good morning, everyone, and thank you for affording me the opportunity to speak to you today. My name is Terri Swanson, and I'm the CIO for Cigna Pharmacy Management.
As Phil discussed, I'm going to take you through more of an end to end process flow and try to highlight some of the various security measures that are in place in the electronic prescribing industry today. I think you've heard a better level of detail from the individual entities.
I'm going to try to refer back to the testimony of the networks and of the WebMDs and DrFirst on the prescriber application side but try to put these pieces together and illustrate how there are many, many, many different security mechanisms in place as a prescription flows through the process today.
Starting at the prescriber practice side, the first thing that I want to re-highlight, I guess, that the technology vendors highlighted this morning, is that the point of care application providers do authenticate these providers. They do a fairly thorough job, as thorough as possible, credentialing them to insure that they are indeed allowed to prescribe. So that all happens before a physician ever gets a user ID or password or any means of accessing that prescribing technology.
From a security standpoint, authenticated prescribers are granted access to the technology and use a user ID/password or more – you heard about a PIN added to that. There are a variety of different authentication mechanisms that different technology providers use, but all of them are contingent on credentialing that provider first.
Once the prescriber is using the system, prescriptions are sent typically to a point of care centralized application server, so you see moving out of the physician's office and into an application server. That transmission is sent through an encrypted channel, a secure channel, and it's always 128-bit encryption or higher. So this is a very secure protocol that's happening.
In addition, there are typically contractual relationships that govern the ability again of the physicians to access these systems. You heard this morning about how those contracts also may govern delegation of authority to other people in the physician's practice.
So in addition to the technical security mechanisms in place, there are also a series of contracts that are in effect.
Last but not least, in the case of wireless technologies, there are additional security and encryption mechanisms that are technology dependent that are also in place to insure that the prescriptions cannot be altered or intercepted or inappropriately accessed.
So what you see here is a variety of different security mechanisms in place in the physician's office and then a secure channel that gets that prescription from the physician's office to a centralized server.
Once you're at the centralized server, the point of care technology vendor and the router -- or network as I think we've been referring to them in the past few days -- verify each other's static IP addresses, their own IDs and passwords before opening a secure channel, again, a secure, encrypted channel, to transport that prescription.
One thing that I want to highlight here is that the server-to-server handshake that you'll see at every step along the way here typically does employ server side digital certificate technology, so that portion of PKI is used between the individual servers. It's in very widespread practice – it's feasible, it's practical, and it's working.
So I think when we talk about PKI and the challenges with PKI, the challenges really lie in that end-to-end individual physician to individual pharmacy type of environment rather than the server-to-server environment that we see in the networks as they're constructed today.
The other thing that we haven't talked a lot about this morning anyway is that there are significant internal assessments that each of these environments go through to insure that they are secure. Most of these servers are in very highly protected data centers that go through rigorous security audits on a very routine basis. They employ security scanning tools for intrusion detection and so forth, a variety of technologies, again, that are and have been in widespread use.
And I think it's important to understand that once the prescription is flowing through this environment that these are very, very secure environments and the industry has invested a lot in protecting those systems again not just for prescribing but for the broader applications of other types of health care EDI. So it's an extremely secure environment, highly monitored.
Finally, the use of PHI in this context must in accordance with the HIPAA standards and so there are also those standards that are governing this entire environment.
To step forward to the router, or the network, again, many of the same mechanisms that I just talked about – the router will do a handshake with the point of care technology and the pharmacy, so the router is playing that role connecting to both sides, again, prior to opening a secure communication channel typically which is enforced with digital server side certificate.
On the security side, the router adheres to security policies which are consistent with the HIPAA guidelines, as we talked about, and again, those same internal assessments are in place just for making sure that the physical environment and the technical environment is appropriately guarded.
Other things that routers do to try to insure I guess that prescriptions cannot be used for the wrong purposes or falling into the wrong hands – the routers maintain typically only enough information to support routing, auditing and technical troubleshooting and so forth.
I think it was a good point made earlier this morning that it would be helpful to the industry to have some guidance about what is enough perhaps and what is too much so that those routers and other vendors along the way do not have to guess at this, because when you look at the process, you need to be able to piece together the audit trail from the physician's office to the server system to the network to the pharmacy and each of those, you need to log and store the appropriate information so that audit trail is preserved from end to end.
And finally, the router cannot view or modify the prescription other than for standard value added services such as translating either between versions of a standard or between messaging standards.
Okay, and finally, the prescription has arrived at the pharmacy. Again, there's a similar kind of handshake at the server level that is secured. The pharmacy does have a cross-reference that links back to the physician. This is used primarily for routing purposes but may provide an additional level of authentication.
Again, from an audit perspective, the pharmacist does have the right to contact any one of these steps along the way, but typically they're going to go back to the physician if for any reason they feel there's something inappropriate or suspicious about that prescription once it arrives in their system.
We've talked about the audit trail already and I think we've talked about authentication.
So that's really a summary of where end to end the various security standards lie. And I guess in wrapping up, I would like to highlight and agree with some of the recommendations made earlier this morning about the need to set a minimum standard that is very secure, much more secure than today's paper-based, fax-based or telephone-based systems and to also allow the industry to continue to evolve.
The industry has employed more and more and more security measures over the years and will continue to do so, so I think allowing for that minimum floor and then additional things that go beyond will continue to raise the level of overall assurances that we have, moving forward.
Questions, Answers and Comments
MR. REYNOLDS: Simon had to step away and take a call and he asked me to coordinate the questioning going forward. Any questions from the Committee?
DR. WARREN: I just wanted to thank you for the drawings. I mean, to split it out into each of the steps so that we can really get our arms around what happens at each step instead of trying to lump it all together and manage that complexity. This is wonderful. I just need a chance to study the drawings now.
MR. REYNOLDS: Okay. Stan, you have a question?
DR. HUFF: You and some of the other folks, your recommendation has basically been let's adopt best practices. Do you feel it would be appropriate for this Committee to actually specify the best practices that should be adopted in our recommendations to the Secretary or do we leave that for a proposed rule-making process, or what? That might be a question for staff and other people here as much as for you, but –
MR. ROTHERMICH: Our suggestion here was basically that these items under each of these categories could be the standard. In other words, defining the best practices, the point of care vendor authenticates the physician before giving access to the system.
The level of detail at which you specify that in a standard I suppose is debatable but there are certain minimum levels of things that you could require vendors to do so that if they complied with the standards you suggest, everyone would feel confident that this is a secure, authentic prescription.
I think best practices as a term is a little too vague to adopt as a standard but as we've tried to define here and I suppose we could argue whether there's a lower level of detail we might want to get to but what we've tried to argue is this is the definition of the best practices, and if all of these things were standard and everyone could feel comfortable that everybody in the chain is doing these things, mission accomplished.
MS. SWANSON: Yes, I think the recommendations can focus on the functionality that you want from the system. So, for example, networks must employ intrusion detection software blah-blah-blah.
There are probably other recommendations and standards, for example, the HIPAA standards, that could be leveraged to get to the appropriate level of detail. But I think it should focus on the functionality rather than specific technologies to the extent possible so that there will be some technologies, like recommending a minimum of
128-bit encryption et cetera, that you'll want to specify, but I don't think you want to drive to a level of detail that makes it difficult or makes the industry have to adopt a specific technology versus come up with efficient and appropriate ways of solving the problem. I don't know if that's helpful.
MR. REYNOLDS: Judy, thank you for the charts. I want to challenge from a – [laughter].
All the players we're hearing from are the big players. As you see e-prescribing going forward, are there going to be – you got over here on the left hand on all your charts is the clinical practice management. I know a speech I gave in North Carolina I went through the first four pages at WIDI before anybody put up their hand up that they recognized any of the practice management systems that we were dealing with.
So we have a lot of the star players and the big players in here. Does your chart come apart anywhere as we get into the mom and pop practice management system? Do they have to use the switches? I mean, in other words, this is a good drawing for the people that have been here with us along this way. Does this drawing hold as we get into the real world and this passes and then it becomes free enterprise and everybody jumps in?
MR. ROTHERMICH: I think it actually helps the situation. If you talk to many of the point of care vendors today, they've written interfaces with certainly more than just the big guys. They can profess to how many interfaces they have written primarily as they come across them.
MR. REYNOLDS: Point of care, do you mean –
MR. ROTHERMICH: The technology vendors. I'm talking about the people who would provide the software for electronic prescribing actually interfacing with a practice management system.
And the practice management system is still extremely fragmented where you've got a few really big players and quite a few mid-size players and a whole bunch of little players.
But to the extent that you can create a standard and electronic prescribing becomes sort of the order of the day where physicians are expecting it and expecting to be able to do it in coordination with their practice management system, by creating a set of standards that are clear, that tell each of these practice management vendors "if you build it this way, it will work," actually reduces their cost of entry and makes it easier for everybody to play across a given platform.
I think one of the reasons that some of the littler players aren't jumping in, whether it's by building a solution themselves or partnering with somebody who's got one, is they just don't have the resources because they're small.
And I think there might be some backward integration where if you had a set of standards and these smaller practice management systems wanted to get on board, they could go to the electronic prescribing vendors and do affiliation agreements essentially where they cooperate with each other. It's relatively easy to make those interfaces.
The problem the point of care vendors have had is a lot of the practice management systems are closed systems, so they'd either have to hack in or they'd just have to say, we can't work with that one, where I think if you create a set of standards and it becomes an expectation, it becomes easier for everybody to get on board.
MS. SWANSON: I'm approaching your question in a slightly different way. I think the drawing does hold and what I would suggest is that we're not saying that every single piece of this picture needs to be in place.
So the suggestion isn't that every cog has to go through a central server and a network. The suggestion is these security authentication standards need to be in place at those different points in the chain.
So if I have a practice management system or an e-prescribing system in the physician's office that connects directly to pharmacies in a region, that's fine. But that server-to-server authentication still needs to employ all of these different function points for that to be considered a legitimate and secure electronic prescription.
So I do think that the diagram is helpful in that this is typically the way people connect and yes, this is mostly how they're going to do it, and in the physician's office, big or small, these vendors do connect with the various networks who you've talked to and they have gone through the certification processes, so I don't think there's a competitive issue at all there.
But more importantly, I think with the security standards, you could use different connectivity models and still have a very secure e-prescribing process.
MR. REYNOLDS: Also on the chart, since the clinical and practice management vendors are not covered entities, and the charts say that all this is under HIPAA, using HIPAA standards and everything, so that's where I think it also is an issue because they aren't. They don't necessarily use the standard, they aren't required to use the standard, and they aren't covered by the standard.
And so do you see this chart backing up, as I mentioned earlier today, backing up, that if it's e-prescribing, then it pulls them in under that and they have to meet those standards? Is that what you meant by the way you drew the chart or did you still want to leave that out there as an uncovered situation?
MS. SWANSON: I would support making them covered entities. I think today, because the next link in the chain is typically a covered entity, they're making those requirements contractually of that partner to connect, so I think the reality is those entities, even though they may not be covered, they're living up to or exceeding the standards because the rest of their business partners expect it and require it of them. But I think your suggestion of making them covered entities would certainly eliminate any debate or confusion on that part.
MR. ROTHERMICH: The only question I have, and I'm not a HIPAA expert at all, but I agree with Terri. I think the HIPAA security procedures are really in place. The only concern I would have is to the extent you designate a point of care software company as a covered entity. I don't know the full impact of that, particularly from a cost perspective.
And again, if we're trying to drive adoption, have we accomplished what we're trying to accomplish from a HIPAA perspective as far as making sure people are treating this information securely according to what HIPAA dictates, and I think we are, if you call them a covered entity, does that add additional cost for their operations and create another barrier to full adoption because they've got one more piece of cost to figure out how to create a business model around supporting?
And that's been an issue to date. You know, everybody says doctors don't what to pay for anything. The more expense you load onto these companies, the more they've got to find revenue streams to cover them.
MS. SWANSON: I would agree with that. I am also not a HIPAA expert and I don't know what other requirements in addition to the technology requirements would really be placed on those businesses.
So the question of covered entity is probably a large question, but certainly from a technology standpoint, it would make it cleaner.
MR. REYNOLDS: Any questions from the Committee?
DR. WARREN: I have just one, and it's not fully formed in my head, but in looking at your drawing, where do you see companies like WebMD and DrFirst entering into the drawing? If you had to map into there, where would you see those happening?
MR. ROTHERMICH: I think DrFirst is in the second column. I think WebMD is an example of what Terri was talking about, that not everybody is going to have four steps, because WebMD is both the practice management system and the point of care electronic prescribing because they've got them integrated.
MS. SWANSON: And they're a router because Envoy has part of the company as well. So WebMD actually fits in the first three boxes in this particular model.
MR. ROTHERMICH: Except that with respect to prescribing, they're leveraging ProxyMed.
MR. ROTHERMICH: So ProxyMed would be in the chain for prescribing.
DR. WARREN: So from that perspective then, your drawing still holds pretty good to help us think about authentication and security and that.
MS. SWANSON: Yes. The way that you might think about these boxes is think of them as roles as opposed to discrete companies. So a company might be playing several roles in this process – the role of routing the prescription to the appropriate pharmacy –
DR. WARREN: You've got them drawn there almost like swim lanes.
MR. ROTHERMICH: And if you look at the bullets under each one, there's consistency there, so it's really if you're following the rules in the first step and you skip the second step, you're going to be okay as long as the third –
DR. WARREN: And then in your solution slide, again you mentioned the wonderful word of "preemption, except you phrased it a little bit differently, so again I want to be sure I understand what you're suggesting. You said "clarify by rule that these standards supersede state laws and regulations."
So does that mean as you are identifying your best practices over here for authentication, audit trails, that would apply to different parts of state laws so preemption would not be this overall preemption; it would be in these different roles?
MR. ROTHERMICH: Well, as written in the MMA, part of the difficulty is interpreting what superseding any state law or regulation deals with these issues. I think the solution down here about if you follow these procedures, the procedure is deemed valid, I think gets to some of the state laws about what a pharmacist is required to do to validate a prescription.
And the testimony yesterday from NABP I think made a very good point, where preemption makes perfect sense, but let's make sure we solve the whole problem. And so there may be some analysis necessary, say, when we write the rule.
And when I say "clarify by rule" here, I mean I think there's a distinction that probably needs to be made, the extent this Committee comes up with standards, a recommendation for the standards, and NCVHS comes up with standards, then the Secretary writes the rule.
And I think when I say "clarify by the rule," we're talking about the Secretary interpreting the statute to say these have to preempt for the statute to accomplish its purpose.
And then when it comes to what is it exactly we're preempting, I think you have to get to some level of detail to make clear that what we're trying to say is anything contrary that deals with security or authentication of electronic prescriptions is preempted and you don't need to make an exhaustive list and those sorts of things get resolved by litigation.
But if it's done clearly enough, then it should be clear to the states that if we're talking about rules for pharmacists relating to authenticating a prescription or rules relating to routing a prescription, that these are going to be covered.
I think that's the key point. I mean, there may be some flow-over from that, but I'm not sure we need to go there right now because the real purpose here is to make sure we've solved the security and authentication piece.
DR. WARREN: I appreciate that. Thank you.
MS. SWANSON: I think we are also -- just because it's not explicit, but you just said it, so I think our intent is also to solve the provisions that make it impossible for routers and other intermediaries to carry the prescriptions, with the example of the Georgia law that we saw. The way that that's written doesn't necessarily fire on security and authentication for me, but that's clearly a part of what I think the problem is that we need to solve.
DR. WARREN: Yes, I like the way that you're phrasing it, of taking best practices and then tracking them through to the rule-making. I think that's probably the strategy. It's not an umbrella strategy; it really is looking at the issues. Thank you.
MR. REYNOLDS: Simon, I'll turn back over to you. I don't think there were any other questions from the Committee, so if you have any, you may want --
DR. COHN: They probably have already been asked. I'll be brief with the subcommittee during the break.
Well, is there anything else? No? Gosh, I miss Michael Fitzmaurice not asking a mathematical question today.
MR. ROTHERMICH: I don't know anything about math.
[Laughter.]
DR. COHN: I actually was trying to remember logs yesterday and I found that it was a high school discussion, which has been many years ago, for those of you on the Internet.
I think with that we're actually running early, which is good, since we've got a long afternoon. I'm going to suggest we adjourn now for lunch. We will reconvene – gosh, I'm giving this not quite 11:30. Shall we try to get an earlier start, say, 12:30? I guess I would ask our initial testifiers, which is Mike Griffiths and Mike Simko, are you all okay with starting early?
Okay. So we'll come back at 12:30 then. Thank you.
[Committee breaks for lunch at 11:25 a.m. and resumes meeting at 12:40 p.m.]
DR. COHN: Okay. Well, our session this afternoon describes the pharmacy perspective, and I want to thank both Mike Griffiths from Albertson's and Mike Simco from Walgreen's. Thank you both very much for coming and joining us.
And I think, Mike Griffiths, you're on first, right?
PARTICIPANT: They're coordinating.
DR. COHN: Oh, you're coordinating. People are throwing me off here, people are actually doing this stuff together! I will thank you. And obviously, we will have to probably call them "Mr. Griffiths" or "Mr. Simco" because talking to "Mike" is not going to work here.
[Laughter.]
DR. COHN: But thank you very much, whichever one – they're coordinating, okay. Please.
AGENDA ITEM: Presentation – E-Signature: The Pharmacy Perspective – MR. SIMCO
MR. GRIFFITHS: We actually were in a different order, but since we got moved up to 12:30, we thought we'd change it.
MR. SIMCO: Hi. I'm Mike Simco from Walgreen's. I'm Manager of Pharmacy Systems. And I really appreciate the opportunity to once again address this Committee in the area of e-prescribing and today's topics of electronic signature and security.
For 104 years, Walgreen's has been in the pharmacy business. We take great pride in providing health care in our stores. Currently, we have close to 4,700 locations in over 44 states and still on an aggressive growth path.
And we have embraced e-prescribing for a long period of time. Well over 10 years ago, we initiated what we believe is the first electronic transmission of prescriptions between physicians' offices and our pharmacies. Although it started with a very rudimentary email-type system, we grew that and saw the benefits from that and grew that into a very robust application.
Recognizing the need for pharmacy participation, market participation, and a greater group of both prescribers and pharmacies in order to make electronic prescribing move forward, we sold our pharmacy program not once, but twice, and currently to ProxyMed, who has made further developments in that functionality.
We recognize the value of electronic prescribing in both the efficiencies it brings but more importantly, I think, in the quality of health care it provides.
MR. GRIFFITHS: Mr. Chairman, members of the Committee, I'm Mike Griffiths from Albertson's, and I'd like to thank you for the opportunity to be able to meet before you this afternoon. Albertson's has approximately 2500 stores in 37 states across the country.
My past experience – I served as a pharmacy manager in retail pharmacy for over 20 years and then a few years ago I moved into administration and pharmacy operations, worked there for several years; currently, I work in the IT department, giving advice on and assistance with privacy and health care security matters.
Again, thank you for the opportunity, and Mike and I would like to speak on behalf of all the retail pharmacists out there as best we can today.
MR. SIMCO: I kind of want to take you through the path of prescribing a little bit.
Today, we get prescriptions in a variety of manners. One prescription written by a prescriber is not always on a prescription pad. In my practices I have seen a variety of ways prescriptions have arrived at pharmacies, anywhere from pieces of torn paper to back of menu cards to back of greeting cards to glitter to markers of various colors, prescriptions of various colors, shapes and sizes. One guy I remember was into calligraphy.
[Laughter.]
MR. SIMCO: Others I wish were.
[Laughter.]
MR. SIMCO: And those were all legal prescriptions.
And in fact today, a physician could pretty much take a crayon and scribble on a brown paper bag a prescription for hydrocodone and it's a valid, legal prescription as long as there's a valid doctor-patient relationship.
And what we have seen is – the testimonies heard yesterday and today – pharmacists and pharmacies are responsible for approving the validity of prescriptions.
And today's method and methods of receiving prescriptions provide a great deal of challenges to pharmacists not only in the interpretation issues, the legibility issues that occur, information that's missing that a pharmacist is required to verify with the prescriber, but also the authentication of those prescriptions.
Today's society, and proven in the volumes of our pharmacies -- and I speak for Walgreen's and I know Albertson's and the CVSs and everyone else out there -- pharmacy volume, pharmacy business is growing, and it's growing rapidly, and today's society is very mobile. It's not so much the corner drugstore anymore.
So many of our stores that have relocated in urban areas in downtown locations don't always have a very personal relationship with physicians or a personal relationship with patients.
And so just by recognizing a signature or recognizing a doctor's name or recognizing a patient is losing its importance and predominance in the prescription filling process.
And so we have to rely on good faith, we have to rely on a pharmacist's judgment that that patient, in data systems that we have, is valid and that doctor-patient relationship exists before filling that patient's medication.
Today, prescriptions can be preprinted and in often cases, physicians do pre-sign prescription blanks, and many times we'll be notified from a physician that I think some prescription blanks may be missing.
And then again the pressure is on our pharmacists and on our stores to police when those prescriptions arrive and authenticate. And in all those cases, the delay of getting the medication to the right patient occurs.
Prescriptions come by phone, and again, with today's society and volume of prescription business, it's difficult to recognize the caller on the other end. In some cases, pharmacies may have a good relationship and a person relationship with particular physicians' offices, but they don't always recognize the caller; we don't know where the call came from.
And then there's always the prescription is valid if it's from the prescriber or the designated agent. And I use the term "agent" very loosely. I've gotten prescriptions from physicians, from office personnel, from spouses, from housekeepers and children and family members of physicians that you could hear in the background they're relaying information back and forth.
And there's never an audit trail. In today's world, if we had a discrepancy on a prescription that maybe was brought in illegally or maybe it was even a physician miswriting a prescription in an illegal manner for a controlled substance, we have no audit trail on a phone call. It's a valid way of receiving a prescription and a valid way of dispensing to the patient, but we're left with no audit trail.
And again, prescriptions not done electronically, there's always the misinterpretation, the miscommunication or essential information.
So when an error may occur, sometimes it's on oral prescription, you can say, well, that's what the physician's office said, and the physician's office would say, oh, no, that's not what we said. And then it becomes we have no proof of liability. And not only in errors on prescriptions but also in the liability as to the legality of the prescription or the validity of a prescription.
The area of faxes have been growing and again, even with faxes, we don't always know where a fax came from. There's also legibility issues. Faxes blackened and writing disappeared over periods of time. Some states don't recognize faxes for some classes of prescriptions as being legitimate. And again, in many cases, it requires the pharmacy staff, the pharmacist, to make a phone call to verify information from a physician.
All these are legitimate means that prescriptions are delivered to pharmacies and what we're concerned about has always been our viewpoint on electronic prescribing is why make that practice more burdensome? It's been difficult and a slow, deliberate process in getting physicians' offices to use e-prescribing.
I can tell you that we're highly encouraged over the past year that electronic prescribing has now been reenergized. It's growing rapidly. We're seeing huge increases from all over the country in our stores as to the amount of electronic prescribing that's going on.
Again, the big benefits – the readability because of text messaging, all the necessary information is there.
And the big key to e-prescribing is the integration into a pharmacy host system. And with that integration is reduced key strokes because all the fields are pre-populated, transcription errors are eliminated.
There's also the issue of security. In the various types of practice management systems and physician software programs that have to do with e-prescribing, there's a sign-on that's required and an ID at the prescriber's office. There's always an electronic trail of a transaction log, and in the past we have used that and it has proven to be extremely beneficial. It does work and it works very well.
We have maintained extreme secure connections between physicians' office systems to ProxyMed and
SureScripts and then between SureScripts, ProxyMed to our pharmacies. We have dedicated lines with encryption. Our pharmacy system is protected by numerous types of security and firewalls that there is no messaging, there is no entry into our system that can take place without proper authentication.
And then even in our physician database we indicate on a physician's registration which doctors are in e-prescribing and what system they're on so that we know if prescriptions come from a particular physician, he's authenticated in our system for e-prescribing and we know that that's a valid transaction.
The use of modern technology has the potential to transform the delivery of health care for the better, and so without a heavy-handed regulation or upheaval in the health care sector.
What we're saying is that in today's world we get prescriptions a variety of ways and electronic prescribing is meant to make the whole process better, it's meant to make it more efficient, it's meant to improve quality assurance.
But we can't have two kinds of standards. We can't have such an easy way that I could pick up a cell phone and call in on a controlled substance prescription to a pharmacy – and that's valid and that's okay – but I can't send it electronically.
Between us, between our pharmacies, and the pharmacy aggregators, the ProxyMed and the SureScripts, again we have a very secure connection – private data circuits, encrypted messages and standards that prevent altering transactions.
And those NCPDP standards that we use today, I know it was talked about that if we were at certain version levels, they wouldn't have to do the routing and open up the headers, and that's true.
And it's incumbent upon pharmacies and practice systems to try to be on as close a version releases as possible and the closer that they are and the more compatible they are, the more secure, the least amount of work needs to be done to rout prescriptions properly.
Again, pharmacy systems are protected by firewalls, encryption, no unauthorized access, and every single transaction we do in our pharmacies today, every single electronic refill request, renewal request, we send out to physicians, every new prescription response we get back – denials or any other type messaging – we keep very detailed, accurate log files that can be reproduced over any extended period of time.
We also have encryption with over the Internet with VPN connections utilizing SAL. Our prescribers have
unique addresses in our database so that even if a physician is using e-prescribing and maybe has multiple locations, we have that physician with unique IDs for each of those locations, so for a particular patient which may see a physician at some site, we can rout prescriptions correctly to that site.
We have registered users, unique pharmacy identifiers using the NCPDP provider ID, and a unique sender ID is an electronic signature. And again, we've all heard the definition of electronic signatures.
You've seen this chart before. It's very well done, very valid. You'll hear about it again. I think Lynn from NCPDP will be testifying.
Again, this structure does work. It works over a variety of different kinds and types of connections and participants so that you can use aggregators, you can use stand-alone physician e-prescribing systems, you can use systems such as WebMD which not only has e-prescribing capabilities but is an office practice management system.
E-prescribing in today's retail environment, there's security that's adequate to insure authentication. There's no immediate need for e-signature or digital signatures such as PKIs.
We're not saying in pharmacy that that may not be the ultimate solution and we're not opposed to as secure and as authenticated signature retrieval and verification as possible. What we're saying, though, is there's a very good system in place today and we don't want to have a barrier to e-prescribing moving forward, and we're very confident and feel very comfortable that those systems in place today work very well.
We think that there's a huge complexity to the use of PKIs. Today we have bi-directional capability with prescribers, they use secure passwords on both sides, and we think the existing infrastructure is very secure.
Use of PKIs is a very complex process. I've attended several presentations regarding PKIs in pharmacies and what I came to understand, that each prescriber would have a PKI, each pharmacy would have to have a PKI, each pharmacist within the pharmacy would have to have a PKI, and if that pharmacist worked in different locations, a different PKI for every location they worked at.
And it becomes an extremely burdensome, tough, complex, sounds expensive, way to manage a system that already works very well. And again, it may at some point be the ultimate goal that everybody needs to work for, but we think today that the systems are find, the security is adequate, and we should keep e-prescribing moving forward.
We also think PKIs really have no guarantee of security. Today's world – we heard testimony may give signed pads to various members of their office staff or authorization for prescription renewals. Same thing with PKIs.
I would think that physicians may give their smart card or token to a member of their staff in order to do prescribing or handle things when they're busy and in that case we have no 100 percent proof that that prescriber is the one that sent that prescription other than that's the person that somebody is going to hold legally liable for it.
Today, various ways of authentication exist – passwords, biometrics, secure connections, encryptions, identifiers. They all are working today to various degrees. Some, we're still looking for improvement in the technology, but everything that is in place today gives us a very confident trail of insuring that prescriptions that we receive electronically we have much more faith in than any other legally recognized method of prescription arrivals in our pharmacies.
AGENDA ITEM: Presentation – E-Signature: The Pharmacy Perspective – MR. GRIFFITHS
MR. GRIFFITHS: And as pharmacists, we'd like to encourage the growth of e-prescribing. You've heard the testimony that the e-prescribing environment today is a big step forward from the legacy (manual) process.
Our goal is administrative simplification. We want to improve the quality, safety and efficiency of the health care system. And the challenge we've got is to avoid over-complication and introduction of burdensome requirements that are not imposed in the non-electronic process.
Our solution is to implement e-prescribing architecture that supports all prescriptions, both controlled and non-controlled.
Practitioners, pharmacists and patients need encouragement and training in order to begin implementing e-prescribing and the benefits are not going to be realized if technology is perceived as too onerous or complicated.
The HHS Fact Sheet, HIT Report-at-a-Glance, on July 21st, '04, had a comment that I thought was interesting: "The benefits of information technology have taken hold in other sectors but the innovation that has made American medical care the world's best has not been applied to health IT systems." We have to ask ourselves why.
We need to address perceived lack of return on investment and non-financial issues such as training requirements and workflow modifications both at the physician's office and in the pharmacy. We have to reduce the risk of investment. Low-cost, simple to implement systems will be much more readily embraced by physicians and pharmacies. Simple, low-maintenance technology will be more readily accepted by small practitioners and pharmacies, especially those in rural environments and in small mom and pop type stores.
E-prescribing benefits patients. It improves the efficiency of the prescribing process. New prescriptions arrive faster, refill requests are processed faster. Pharmacists are able to spend more time providing pharmaceutical care and counseling to their patients, less time interpreting and clarifying hard to read prescriptions and time spent on the phone.
It reduces the potential for errors. Cost reductions realized by health plans are going to happen because we're going to have increased therapy and compliance by the patients. Counseling improves the effectiveness of the therapy and reduces cost due to improved therapeutic outcomes and increased compliance.
It improves safety and it establishes a dialogue and rapport between the patient and the pharmacist.
A large number of prescriptions that are written never are taken to the pharmacy, and with electronic prescribing, those prescriptions are going to be delivered to the pharmacist and a pharmacist has a chance to review those with the patient and consult with a physician if necessary to find out why the patient didn't get that prescription filled.
As far as patient care, many patients receive a combination of prescriptions to treat an illness which includes controlled and non-controlled medications. The benefits of e-prescribing would be mitigated if a practitioner could transmit a prescription for an antibiotic by e-prescribing but then would then have to hand-write a prescription for the corresponding cough syrup with codeine, for example.
So in order to realize the benefits and efficiencies of e-prescribing, we've got to make the system efficient. Important concepts to keep in mind – there's no substitute for a pharmacist's professional judgment. Ultimate responsibility for insuring the authenticity and accuracy of prescriptions rests with the dispensing pharmacist no matter how it's delivered, manually or electronically. If a pharmacist has any suspicions about a prescription regardless of how it's signed, he or she will contact the prescriber.
E-prescribing is secure. It exceeds the current methods. The security in place is adequate to support the e-prescribing process.
And let's keep it simple to start. Over-complicating the process and waiting to implement the perfect system is going to prevent us from realizing the benefits that can be derived immediately.
Thank you very much.
Questions, Answers and Comments
DR. COHN: Okay. Well, thank you both for some very good testimony. I see Judy's hand up, Steve, Stan.
DR. WARREN: I just had a question as a result of this. We've heard earlier that we need to make it where the pharmacist is assured of the authentication of the signature. From your perspective as pharmacists, what would we need to put in place to help pharmacists agree that the authentication has happened, other than calling back to the office?
MR. SIMCO: In the contractual business arrangements we have today with the aggregators, there's a certain amount of certification that has to take place between physicians, management systems, or physicians' writing systems and those aggregators and the practice management systems. And when we're given the new physician registrations that may now be engaged in electronic prescribing, we give those physicians new, unique IDs.
If that prescription message that arrives into our system matches those IDs in the secure connections that we have that exist between us and those partners, that gives our pharmacists a very high level of confidence that that prescription is authentic, it came from that physician, the physician intended to send it.
As we go forward with different levels of encryption and different types of identification, whether the use of biometrics or anything else in physicians' offices, all that really comes into play is being a much more higher, secure system than what's in practice today. And again, because of the pre-registration identification and validation of who's registered on the network, that all kind of comes into play, has given us that level of security.
DR. WARREN: So what you're really saying is that the pharmacist needs to be assured that whatever software package they're using does the authentication and they can trust it?
MR. SIMCO: Exactly.
DR. COHN: Okay, Stan?
DR. HUFF: Yes – in trying to make an analogy back to electronic health records, many of the same arguments came up in terms of security for the electronic health record in the sense of saying somebody in a white coat could walk up and grab my chart on the floor and we shouldn't hold electronic medical records to a higher standard than we hold paper records.
Ultimately, I think we have stronger security on electronic medical records than we do paper records. And the justification for that was that we have increased risk because basically, as things become network, you have more risk because people, anybody anywhere, has the opportunity to try and break in, and if the information is obtained, they have the ability to disseminate more quickly, be more anonymous, to do population queries, all kinds of things that you couldn't do easily in a paper record.
In thinking about this, do you see any situations of that kind here? Do you see where electronic prescribing increases our risk in some way that would require us basically to have a higher standard for electronic than for paper?
I can't think of any, but I'm wondering if you guys have thought of any. I mean, is there some chance now that somebody could set up an operation that would automate some kind of fraud or other things, any kind of risk, any kind of new risk that you see from this that goes beyond the risk that we already have with paper?
MR. SIMCO: What you bring up is a great point and all that could occur invisible to everyone else where in a paper society you would see someone in a medical records area and now you can get somebody potentially trying to break in and no one knows it's happening. However, for a long time our pharmacies have been
computerized. Our pharmacies really have been engaging in electronic medical records for a long period of time, and we take very secure, deliberate, expensive, detailed, redundant steps to protect pharmacy information. And pretty much virtually at the point where I could say that we have been successful in securing our pharmacy information that makes it free from any tampering or entry from unauthorized access.
I think the same thing is going to have to eventually occur at physicians' offices. I'm not concerned with the transmission of prescriptions from a prescriber through a network to our pharmacies.
I think that they need to build the same kind of safeguards around their electronic medical systems in their physicians' offices and to have security and firewalls and encryption there to protect the records that do exist.
But as far as the transmission itself, I don't have any issues with the authentication if I know that it came from that physician's office and they're properly registered and that messaging came through electronic means or e-prescribing means. I have confidence that's secure.
I think the other part of that, though, is that they build adequate security on the electronic medical records part in their offices and whatever other interoperability and connections they may have to insure the integrity of those records.
DR. HUFF: But I'm just trying to think of some innovative way of gaming the system that could occur electronically that couldn't occur –
MR. SIMCO: And I can't think of one, either, and the other thing I could say on it is the advantage is that there's a very good, very detailed audit trail that exists and at least that we can know if something was an invalid, unauthorized prescription or denied as being sent, that we have that audit trail and we'll go back to the physicians' offices.
And I think in many of the practice management systems that occur, they're able to review their transactions on a regular basis and so that they can have very dynamic feedback as to these are the messages you sent, these are the prescriptions you sent out, and they can review that on a very timely basis.
MR. GRIFFITHS: I think that's an excellent point, too, and as we go forward, we've just got to constantly be assessing the risks and make sure that we've got, as HIPAA says, reasonable and appropriate measures in place. I think that's the best we can do, going forward.
And I think, again, pharmacy is not opposed to constantly looking for new and better ways to enhance security. I think what we were just trying to say is that there's very good practices in place today and you shouldn't delay the implementation of e-prescribing looking for that perfect model that I think is still some time away.
DR. COHN: Steve?
DR. STEINDEL: Thank you. I guess I'm going to use a little bit of a preamble before I ask my question, but the one thing that I've been finding striking and it crystallized somewhat during your comments is we've heard repeatedly through the HIPAA era "don't make anything more complicated than what existed on paper," and Stan just gave an example of that. And we heard the same thing from you just a minute ago.
But one thing I hear repeatedly is actually you're asking us to make things not more difficult than on paper but better than on paper, because what I've heard repeatedly over the last two days, that we don't really have anything in the paper system; it can be so easily faked, manipulated, changed, whatever, that we have much more security even by using a very simple security system in the electronic world, which is what I've been hearing repeatedly. And I see by your nodding of your head you're reacting very similarly.
And I think, as I mentioned yesterday, I think what we have to discuss and recommend to the Secretary is what level of risk above what exists today, or hopefully decrease the level of risk that exists today, is the Secretary willing to accept, and that's something we'll have to discuss.
But this has been very clear and very useful conversation in this area. I loved the one today about you just telling us about the child yelling across the room. Yes, it's getting more interesting.
But the one thing that I do have with that preamble I do have a question about. And this has to do with terminology, and Stan and I are into terminology so we always pick on that.
We had a discussion yesterday in Kepa's wonderful talk about nomenclature and electronic signatures and digital signatures. And I was looking at your slide and you were saying no immediate need for e-signature or digital signature. And yet, what I'm hearing is you're looking for what other people have called the electronic signature.
We had one person testifying yesterday – I forget for what group – that looks for a DEA number on their electronic prescriptions and that's what they consider to be their e-signature, along with a set of other identification information that authorized the person to get into the system. And by your nodding your head, you agree that that was kind of a subtle difference in –
MR. SIMCO: Right, exactly.
DR. STEINDEL: Okay. And then the next thing I've been hearing consistently – and I've asked this several times – is with non-repudiation. And you've also taken the same path that everyone else has said, and that is, what it logs and the ability to trace transactions so if there is a problem, we have a better way to go back and find out how it really occurred –
MR. SIMCO: Yes.
DR. STEINDEL: -- than exists in the paper system.
MR. SIMCO: Yes, and we have used that in the past and it's proven to work, and work very well.
MR. GRIFFITHS: As health care professionals, we're just continually asking ourselves: What's best for the patient? Continuing with the manual process or implementing e-prescribing? We're always trying to keep the patient first and foremost in our mind.
MR. SIMCO: And your other comment was exactly right, is that just the inherentness of e-prescribing just today is infinitely more secure and much better authentication than various ways prescriptions get to pharmacies today.
And I just talked about a couple, but it is totally much to imagination and to various ways medicine and pharmacies practice, but there is no standard as to what a prescription is outside of somebody writing something on a piece of paper or making a phone call.
DR. STEINDEL: And I think this question has been asked repeatedly of people: What if the DEA comes in with a system that's not exactly like the one you described – i.e., a PKI system?
MR. SIMCO: And again, Mike Griffiths touched on it in one of the slides, is what they were proposing – and they haven't come out with their final regulations – but the whole idea of a PKI I think will just put a barrier on e-prescribing as far as controlled substances are concerned. And I think in the long run it'll affect e-prescribing as a whole.
And many times we get prescriptions from physicians in combinations. You get antibiotics, you get cough syrups, you get discharges from emergency rooms and hospitals – a lot of it's for pain medication, and it's all immediate need prescriptions for, in many cases, very severe discomfort, pain, or medical condition of a patient.
I think what it's going to do is a physician is not going to look at an antibiotic and a cough syrup and say, wow, I can send this one electronically, but here I have to write this one on a scrap piece of paper and it's okay if you take it to the pharmacy and they'll fill it.
That's just going to delay the process. They're not going to do it electronically, they're not going to do two manners of prescribing. What they'll do is just end up writing both prescriptions on paper and it'll just further delay the e-prescribing adoption process. It makes the patient wait longer to get their medication. It introduces the risk of error that occurs today.
So what we're hoping for is that at least on the Schedule III through Vs that the systems in place today should be adequate and satisfy those requirements for validation of prescriptions, especially when Schedule III through Vs I can call in a prescription over the phone, fax it, write it on any kind of piece of paper that exists.
DR. COHN: Harry?
MR. REYNOLDS: Yes. Mike Simco, in your comments, you made a statement that pharmacies give physicians IDs.
MR. SIMCO: In our host pharmacy systems.
MR. REYNOLDS: In your host pharmacy – going back to the picture everybody likes, where are you talking about in this picture?
MR. SIMCO: It would be your far right end.
When it gets to our pharmacy itself, when messages arrive into our database, our physicians are registered with IDs. And in some cases those IDs are unique identifiers maybe provided by the aggregators that we're connected to if those physicians are registered for electronic prescribing.
In other ways we give physicians IDs based on the DEA number, based on their location, based on their address, and if the physicians have multiple locations of practice, they have multiple registrations in our system.
MR. REYNOLDS: You mentioned DEA. Then you think of NPI, you think of the other stuff that's coming out. So would that physician actually have to use that number when they're entering a prescription or is that obviously picked up and done somewhere along here? How do they keep in sync?
MR. SIMCO: I think the software at the point of prescribing would attach that ID to that particular physician and that message that's sent by that prescriber. So when we do receive it, we can validate that that ID is part of the message and part of that physician's registration so that we can rout it and pick the right physician in our database and know that that's the physician that wrote that prescription.
MR. REYNOLDS: So do they have a different one for Walgreen's and CVS and –
MR. SIMCO: No, and I think the ideal manner would be that they would have one registration that would work in all systems.
MR. REYNOLDS: Okay, good. Thank you very much.
DR. COHN: Steve?
DR. STEINDEL: Harry's question just led me to something to ask in the e-prescribing world that's been concerning me.
Today, I get a prescription and I decide I'm going to fill it in my local pharmacy but somehow I got sidetracked and I was driving somewhere else, and I said, oh, I forgot, and it's going to be too late, and I stop in this drugstore and have it filled. And how does that work in the e-prescribing world?
MR. SIMCO: Generally, what we have seen is a physician, when they're writing a prescription, an e-prescription, they'll ask the patient what pharmacy they use and they have that pharmacy listed in their directory. In many cases, some of the software, whatever pharmacy the patient chose previously is automatically loaded into their registration.
And so if that physician then sends them a prescription – and I could speak to Walgreen's on this and maybe Mike could speak to Albertson's – but if they sent that to our system and it was routed to a particular store that was identified by the physician and we would enter that prescription into our system and match your ID and match all the information, if you drove to a different location, again, all our pharmacies are connected, so once it's entered at one location, all our locations have access to that information and we can close it out from wherever it was initially sent to and transfer it to that location.
DR. STEINDEL: Okay, but what if I decided to go to your neighbor's pharmacy on my drive?
MR. SIMCO: Then, today several things occur, and it happens a lot. Physicians will call our stores and the patient may show up somewhere else. That pharmacy would have to determine where the prescription was sent to and if the patient knows or a call to the physician, and then they would then transfer the prescription from one pharmacy to another. It cannot do it electronically at this time yet, but we would close out a prescription at one location and transfer it to another.
DR. STEINDEL: So, my summary of what you have just said – if I stayed within the same system, it's a minor inconvenience; if I cross systems, it's a minor hassle factor. But we are able to do it.
MR. SIMCO: You're correct.
DR. STEINDEL: Okay, thank you.
DR. COHN: Okay. Well, thank you both very much. Since Steve asked my question, I don't have any questions.
[Laughter.]
DR. COHN: Anyway, thank you very much. Yeah, I think we've been together for too long here! So thank you very much. Shall we take like a minute stretch break? And I'm hoping that – is Lynn here? Okay, good. Well, why don't we take like a two- or three-minute stretch break and let you and Lori come up and we'll start on our final panel? Is Lori here?
[Committee takes a break at 1:20 p.m. and resumes meeting at 1:43 p.m.]
DR. COHN: Let's get started. Our next session is on e-signature from the standards development organization perspective, and we're delighted to have Lynne Gilbertson here representing NCPDP. We understand that the representative from ASTM, Lori Fourquet, will be arriving later this afternoon, and we'll obviously include here in testimonies when she arrives. So, please, Lynne.
AGENDA ITEM: Presentation – E-Signature: Standards Development Perspective – MS. GILBERTSON
MS. GILBERTSON: Hi. I'm Lynne Gilbertson from the National Council for Prescription Drug Programs. NCPDP appreciates the opportunity to testify on the topic of electronic signature.
As a little bit of history, during the 2000 and 2001 – and it felt like it went for a couple of centuries –
NCPDP members and staff participated on the ANSI HISB "Multi-SDO Digital Signature Project." And this project began with involvement from ASTM, HL7, IETF, NCPDP, and X12.
NCPDP was very active in the paper that was being created and was one of the few submitters of the use cases. That was the last deliverable that we were aware of.
There was a lot of frustration during that project trying to understand how the digital signature world would work because if we took the premise of we've got real time transactions floating back and forth and there's certificates that you have to authenticate.
It became, okay, what if you used certificate authority and I used another? Now, do I have to download files daily from each authority to be able to figure out how to authenticate that you're a new user to that system? How do I do that operationally? What is the overhead to the payload of the transaction?
All that came up, and we just weren't able to get any resolution as far as the paper was concerned.
There were a lot of open issues at that point and we didn't have a lot of industry expertise even reaching out to financial models and other models that we worked on during that time frame. To our knowledge, the project is not active and the paper was never completed. I don't know if it's become something else, but we have not been involved past that point.
NCPDP member companies have participated in the DEA meetings regarding the security being considered for the prescribing of controlled substance prescriptions. Companies have expressed their concern for the lack of health care industry experience and the cost involved in supporting the security being considered.
As noted by some of the other testifiers, it's really important for the continued growth of electronic prescribing to remove or not set up any barriers that could hinder this growth.
One of the things – the fraud and abuse that was brought up – there are statutes, there are laws governing the illegal prescription writing and the prescription dispensing. So it's possible that those are the methods to get the percentage of people who try to subvert the system and not put that on every transaction that is in the way of the electronic prescribing environment.
The NCPDP SCRIPT standard, just as a standard perspective, supports what you would call signature fields because it identifies three levels of sender and the receiver and passwords to go with those.
One of the things – it was mentioned this morning as well – electronic prescribing, as you know, is not a HIPAA transaction. In previous testimony, we did discuss concerns about rolling, for example, the SCRIPT standard, into the HIPAA regulations because some of the problems seen with being able to move forward quickly with versions to continue to evolve and how in a lot of cases we don't have those things ironed out in the HIPAA transactions and code sets of today.
Other NCPDP standards, some which are named in HIPAA, such as the telecommunication and batch standard, also contain sender and receiver identifiers. Although the health care information technology industry has discussed further identification methods over the years through our involvement in other projects and just general discussion whenever electronic signature, digital certificates, all that comes up, further need has not been brought forward to NCPDP for consideration in the standard.
One of the things to consider with the other standards is the information that is contained on a claim is very similar to the information that's contained in an electronic prescription, and we don't hold claims to a different standard other than sender, receiver, authentication, things like that, and so that's a data consideration, that what are we expecting different out of an electronic prescription that we might be expecting differently out of an electronic claim?
So just as a thought.
To prepare for this testimony, NCPDP convened a task group from Work Group ll Prescriber/Pharmacist Interface and Work Group 12, Education – Legislation and Regulation. These are led by Dan Stanek of Caremark and Ken Wittemore of SureScripts. The testimony I'm about to speak reflects their work.
NCPDP Electronic and Digital Signature Recommendations for an E-Prescribing Environment.
The recommended definition of electronic signature supported by NCPDP is as follows:
An electronic signature is an electronic sound, symbol, data string, or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record. NCPDP recommends that NCVHS adopt this definition of electronic signature so as to accept a variety of assurance solutions currently implemented in the industry and accepted by state pharmacy boards.
NCPDP believes that current business practices for authenticating prescriptions, which include user registration and verification processes provided by trusted partners, user sign-on authentication processes, secure message transmission, and auditing processes, are fully adequate for assuring the appropriate delivery of the prescriber's intent to the dispensing pharmacy. NCVHS should recommend a minimum standard for assuring the secure delivery of prescriptions that include these basic processes for all prescriptions, including controlled substances II through V.
The utility of digital signatures depends on the development of a trust infrastructure, which reliably associates practitioners with public signature verification keys. To date, efforts to deploy PKI on an industry scale have been unsuccessful. Requiring digital signatures using authentication protocols such as PKI – either for all prescriptions or only controlled substance – would significantly slow the adoption of electronic prescribing and is unnecessary for securing the electronic prescribing process.
Other auditing or monitoring processes that do not include digital signatures could be employed to provide additional protections for fraud and abuse for controlled substances.
NCPDP recommends that for the purposes of electronic prescriptions, the NCVHS recommend a minimum set of required properties for electronic signatures and situational properties to be accessible for use by business partners.
NCPDP asks NCVHS to recognize that there is no current requirement that the practitioner's electronic signature satisfy strong forms of non-repudiation."
Networks are in place that maintain security without PKI. Organizations that are supporting electronic prescribing have met with the boards of pharmacy are satisfied with the registration, logging, audit processes of the participants.
Consideration that you've heard already is that value added networks and switches who perform valuable services of conversion either between versions of the existing standard or conversion between different messaging standards must be able to open the envelope and provide this process for the participants. We haven't worked so hard on the HL7-NCPDP collaboration to see it collapse.
NCPDP recommends that NCVHS recognize that for the purposes of electronic signature on prescriptions, current assurance requirements can be satisfied by the imposition of a limited set of business rules upon parties utilizing the SCRIPT standard. The pharmacy needs assurance that the identified practitioner intended to issue the particular prescription communicated in the NCPDP SCRIPT message. That the following business rules provide the required assurance:
The electronic prescription application user's interface must present the completed prescription request to the practitioner for verification prior to transmission.
The electronic prescription application must protect against impersonation of the practitioner. Impersonation is precluded, in part, by a registration process that verifies the user's identity and role in a way that reliably associates the user's application access credentials with a practitioner's attributes such as name, medical license, DEA, NCPDP provider numbers, and national provider ID.
Protection against impersonation further requires user authentication procedures to guard against unauthorized access to the user application. Where the user authentication is accomplished across the communication network, use of a secure transmission protocol that protects against masquerading, eavesdropping and replay attacks is needed to prevent opportunities for impersonation.
You've seen the diagram in previous testimony. It shows, from left to right, right to left, the different electronic prescribing environments and the different authentication that is in place at all the different points of view.
It was mentioned earlier as well the diagram represents channel encryption, which is the rout, versus the data encryption, with protections at the user and the server interfaces, secure networks even using public transports for these networks. Like the transportation of HIPAA claims and other transactions that contain protected health information, the access and networking infrastructure has security and authentication at multiple points. Each rout along the way maintains audit and log files as well as registration requirement.
One of the things for consideration is, as we hear testimony, we're trying to figure out what problems are we trying to solve? We have things such as the authentication of the prescriber which the different methods do not control that. Are we trying to protect the transaction in some form or fashion? So we're still kind of stumbling with what is the problem we're trying to solve so that we can address the particular need.
Thank you very much.
Questions, Answers and Comments
DR. COHN: Okay, Lynne, thank you very much. How much questions from the – Harry, did you have a comment, please?
MR. REYNOLDS: A question on – Lynne, if you go to your last page, 5B, I need a clarification. It says: "Electronic prescription application must protect against impersonation." Impersonation is precluded, and it talks about the process.
But basically when you get into the electronic world, the fact that within somebody's system they have set up who someone is doesn't mean that that is the person who's actually firing off the transaction. So this is a pretty strong statement. This sets up an environment that should help preclude, but I'm struggling that it completely precludes.
MS. GILBERTSON: Well, I mean, it's not suggesting that 100 percent of the time it's assumed that it's always the actual human individual or – I mean, it assumes that there is designation going on, that there is controls at the prescriber or the pharmacy systems so that it's unauthorized access.
MR. REYNOLDS: Okay. I just wanted – in other words –
MS. GILBERTSON: Yes, if you're authorized –
MR. REYNOLDS: No, now that you've added those other things that was inherent in here, fine.
MS. GILBERTSON: Okay, yes.
MR. REYNOLDS: Just wanted to make sure; that's a pretty blanket statement.
MS. GILBERTSON: Did you know what I meant, right?
MR. REYNOLDS: I assumed it.
DR. COHN: Okay. Maria?
DR. FRIEDMAN: Thank you. On Number 3, Lynne, you have a very general description, or very general recommendation, that NCVHS recommend "a minimum set of required properties for electronic signatures and situational properties to be accessible for use by business partners." Is there any way we could get a little more flesh on those bones? Sounds good, but what would you like to see if it were an ideal world?
MS. GILBERTSON: I don't want to go there! I can't go to Planet Utopia! I really think that this becomes NCVHS charge the industry with saying what is the floor and what are the required guidelines for use of the signature which starts off with a definition of what the electronic signature is and then takes it to say what are the elements of what consists of an electronic signature.
So if you use the definition of sound, symbol, data string or process that the industry actually define what some of the criteria of that is. If you're going to use a data string, is it a user/password/PIN? Is it a user/password? Is it a – whatever? Is it name and address? Those kind of things.
So it's a recommendation, but I would take it one step further and say that it gets punted back to the industry that says you come forth with guidance of what the data elements should be, because that becomes some of the best practices that we've been talking about earlier, the guidance for what makes a standard level.
Your brows are knitted, Simon.
DR. COHN: Well, I'm trying to get whether you helped us –
DR. STEINDEL: I have a follow-up.
DR. COHN: Sure, Steve.
DR. STEINDEL: Two follow-up questions. The first – I'll follow-up Maria first and then follow up Harry.
WebMD put on one of their slides a set of what they considered to be the minimum requirements for identification in their system of a transaction and the person, individual making the transaction. I forgot exactly what it was, but it was basically a good part of the list of the things that you just enumerated, including identification that would allow trace ability on the transaction itself. It had a transaction ID in addition to the individual ID. Would you propose that as a good starting point?
MS. GILBERTSON: Yes, I think those are common elements to just about any transaction, whether you were talking about a credit card transaction, a claim, an electronic prescription, a registration. So I think that would be the basis of where you start.
DR. STEINDEL: Yes, that was my sense of what I saw when they put the slide up there. That looked like a very good starting point for a recommendation.
MS. GILBERTSON: Right, right. And then it also would identify where's the source of the information to bounce it against. Now, just simply, if I'm going to use a DEA number as one of the IDs, so I have to bounce it off a DEA file to make sure it's real. Those kind of things, and active in all that.
DR. STEINDEL: Does that help clarify the response a little bit, Simon?
DR. COHN: Yes.
DR. STEINDEL: And the other one – I was a little disturbed, like Harry was, when you used the word "impersonation." And then when you responded, I'm probably more confused than clarified on it because if you really mean authentication to use the system, why don't you use that word instead of impersonation? Because when you say impersonation to me, that's a very strong security system. We're going into something like biometrics or very strong, secure, card identification, and so you actually know the human being is the human being that's typing on the keyboard.
MS. GILBERTSON: No, I would agree with that. I'll take that back to the task group and –
DR. STEINDEL: If you make that change, then the paragraph makes sense to me.
MS. GILBERTSON: Yes. And I appreciate that, yes.
DR. COHN: Other questions or –
DR. STEINDEL: I would like to make a comment. I think the comment that you made about the hard work by HL7 and NCPDP to allow the adjudication of that is a very strong message to the subcommittee about the need to open the envelopes and transform it, and we were the ones that asked for that hard work and we're very appreciative of it.
MS. GILBERTSON: Thank you.
DR. COHN: And let me just ask a question about that one because I obviously heard the issues yesterday and maybe it's a question to ask all of our security gurus, electronic signature gurus in back, but I guess I wasn't at all convinced that opening a package made the issue of PKI an impossibility.
It just sounded like what we were talking about was various stages where it was sort of like what we're dealing with is PKI handles D-sender and D-receiver and what we're describing here is manipulation by a receiver to send it on to another entity. And as long as the PKI captures those as separate transactions, there's nothing theoretically impossible about all this stuff.
I mean, what it does is it tells you that it has been modified and tampered, but then from the transformation it remains intact. Isn't that – am I missing something here?
MS. GILBERTSON: Are you suggesting that the prescriber system would digitally encrypt the whatever the prescriber sent on the new prescription, when it got to the router – let's just say someone who's going to transform it from an HL7 to a SCRIPTS message, then a new set of PKI digital certificate is then attached to that as well, and then that whole package then goes to the pharmacy?
DR. COHN: Well, I mean, wouldn't that have to be how it would go? I mean, because otherwise things wouldn't match.
MS. GILBERTSON: Well, but then you've got inner loops and outer loops and –
DR. COHN: What?
MS. GILBERTSON: You would have the inner loop of what the prescriber intended and then the outer loop of what it got transformed to.
I mean, one of the things that would be a problem is whoever's in the inner loop, if they expected that HL7 message to turn into a script, they can't read what's in that inner loop anyway because it would be an HL7 language and their system wouldn't be able to support it anyway if they got in far enough to figure that part out.
And I'm just trying to figure out how –
DR. COHN: Well, I mean, it's an issue of – I'm not saying we should do it.
MS. GILBERTSON: Right.
DR. COHN: I keep hearing this thrown up, and it was thrown up yesterday a number of times that, well, because it's got to be transformed or it's got to be updated. I mean, I thought the purpose of PKI, as least as I've understood from the last two days, is less to assure authentication and more to assure the lack of tampering, and so if indeed things are being tampered with, which may be very appropriate, it just reflects that it has been tampered with something new is applied so people know that it's been tampered with and you know who tampered with it.
And so that's all I'm saying. And if you think I'm way off on this one – I mean, it just seems like this is an a priori death to either transformations or the ability of a VAN pr a software developer or whatever to deal with looking at headers and all that. It just creates a very accurate audit trail.
MS. GILBERTSON: Because what I was also trying to think of is if you just decided to encrypt pieces and parts of the message and those are the only parts you cared about, but I'm trying to think in an electronic prescription what that would be. I mean, you've got patient information. Well, if you're going to transform something from HL7 to SCRIPT, you'd better be able to get into the patient so you can identify it correctly for the receiver.
So I don't see anything that would be outside of that piece.
DR. COHN: I think if we're talking about this that we need to give people flexibility to do what they need to do. It's just more of auditing.
MS. GILBERTSON: Trying to figure out if you encrypted something in the center and then you wrapped something around that, if your system wasn't capable of understanding what was in the center – I mean, because that could still be an HL7 message, for example, wrapped around a script, you're not going to get into that anyway because you don't understand what HL7 messages are to even get in and figure out where I go find the signature and things like that.
Now, I'm a little out of my league, but just from a technical point of view, I don't understand how that would work when you don't know how to read an HL7 message or vice versa anyway. That's the whole point of why somebody's transforming it for you.
DR. COHN: Okay. I had a feeling that I might have enlisted a couple comments, yes.
DR. STEINDEL: Simon, I think –
DR. COHN: I mean, I'm not saying we should do it. I'm just saying --
DR. STEINDEL: -- your analysis of what would happen is totally correct.
DR. COHN: Okay. So how would we handle this?
DR. STEINDEL: Yes, and how would we handle. I mean, if somebody sends a digital signature, encrypted, HL7 message to processor, whatever we call them who does it, who opens it and translates it and then moves it on to a pharmacy in a rewrapped – well, what would have to happen is they would have to re-sign it with their digital signature, with the new steps of encryption and whatever, and pass it on.
And yes, I would feel fairly certain that's actually being done routinely in some areas where PKI is done today, so it's not an unfeasible thing. It just seems like – I don't know.
DR. COHN: I'm not suggesting that that be the answer. I'm just suggesting PKI doesn't do them all, transformations or transcriptions.
Please introduce yourself if you have a question or comment on this one.
MR. HAAS: My name is Jim Haas with WebMD and we do transactions. So a couple of comments on the point that you were making about sort of the interim decryption and recryption message.
That makes a presumption that really hasn't been mentioned here too much, and that is that the sender knows the path of end to end that that transaction is going to take, and the truth of the matter is he doesn't necessarily know that because there are peer to peer arrangements within the networks that says I may not have connectivity to this guy but I have connectivity to that guy and I know how to get from here to there, then he knows how to get from there to the next place.
So while you may know the next destination, you may not know all the destinations.
There's also some redundancy, because from point to point, the telecom, or the pipe encryption, is already in place, so we're already protecting the message from one point to the other point. And if you then put this encryption over that same pathway, you really haven't bought yourself anything that encrypting the pipe didn't buy you.
The real value of the encryption is from originating sender to ultimate receiver because that's really the piece that you're trying to prove, that that message really came from this doctor.
So I think the thought that Lynne had and maybe something that we back at NCPDP need to look at is an encryption – and we've also had sort of two directions of conversation. We don't change the message; the pharmacist has to see exactly what the doctor wrote. And oh, by the way, we do all this mapping stuff. And how do you reconcile those two pieces?
And the answer is that you're very judicious and careful about what pieces can be touched and what ones do not make sense or you just don't touch.
And we've also talked about the concepts of value added networks, and in fact some of the values those networks add is to do some of this translation in behalf of a business partner. They say, well, it's really easier for you to do it in one place than me to go to 500 stores and make this translation. So there's a value add.
But the point is, I think the industry – and you can kick me under the table real hard, if you like – can work towards agreeing on what are the inviolable pieces of that message? And drug name would certainly come to mind, SIG would certainly come to mind, some other characteristics of the prescription.
I think we could arrive at those pieces and say, well, those are the ones that we really need to encrypt end to end because those are the ones that we need to prove haven't been tampered with from end to end.
And maybe the message can be structured in such a way that that tamper-resistant stuff is placed in a certain part of the message, that piece is encrypted and doesn't need to be broken into during the course of the transmission. And that may be a way to have your cake and eat it, too.
MS. GILBERTSON: Although you're going to have trouble with translations at that point.
DR. COHN: Yes.
MS. GILBERTSON: If you don't know where to put the SIG in an HL7 message. It's tough.
MR. HAAS: I mean, I don't know enough about the encryption to say if you can pick up an entire encrypted piece and move it as a block – I just don't know.
MS. GILBERTSON: Yes, if you encrypt data elements.
MR. HAAS: Right. The drug name –
MS. GILBERTSON: As you saw how big each of those encryptions could be. We've got to make some bigger pipes.
DR. COHN: Yes, and as I say, I'm not saying we should necessarily do this. I was just pushing against the infeasibility of it.
Steve, I think you wanted to make a comment, and then we'll get back – we now have Lori and Alan who have arrived.
DR. STEINDEL: Yes, just a comment on this encryption within a message, an encryption within an encryption. And when I mentioned the CDC secure data network, we actually do do that fairly commonly on some types of information where within public health, there's certain types of information that only certain people should see and we put very specific encryption keys on that information as it goes. We decrypt it in the area of public health where it needs to be.
MS. GILBERTSON: Are those real time transactions back and forth?
DR. STEINDEL: No. As I said yesterday, we're talking about a very circumscribed population and a very circumscribed need, and I would not generalize it to the real world, so to speak.
MS. GILBERTSON: And one of the things that I mentioned earlier, as Jim is discussing, if you're doing any kind of encryption between parties and if you need to know end to end, it's very important to talk about the certificate authority environment and how many different CAs would there be and what kind of information would be required to be local on whatever system is actually generating a transaction to bounce off to find out: Do I have the public/private key business? Do I have the ability to ascertain if that's a valid certificate? Things like that. Do I need 10 files from 10 different CAs? Do they interoperate?
We couldn't come to answers with those on the SDO project, so I don't know if there's any guidance from anybody who's done anything yet. There's not a lot of models to play with.
DR. COHN: And I was not addressing any of that. I was just saying that given what we've described, that what you were describing was not the death knell for anything that you needed to or the industry; it just was another – I mean, there actually probably are technically ways to do it, but certainly we all know the issues of interbridge connectivity, about certificates and all of that, is something that would have to be solved for all of this to work or single credentialing authority or whatever.
Now, as I say all this stuff, and this was not actually intended, this question, to bollix us up for the last 10 minutes, but since I've asked the question, obviously our other two testifiers have actually arrived, so thank you very much for arriving, and we have Lori Fourquet – and I hope I am saying your name correctly. I see we are actually trying to get your computer to work with our projector.
And we also have Alan Zuckerman. We do apologize. As you can tell, we're running ahead of schedule, and that's basically what's going on here.
So I guess, Lori, did you want to go first? Do you want to have Alan go first, given that you're having some trouble with the connection? What is your preference?
MS. REED-FOURQUET: Okay, go ahead and have Alan go first, and I'll have my –
DR. COHN: And you guys can play with the connection here for a minute.
Well, Jeff had a comment or question. I mean, we're not done with the questions, either. Jeff was aware that – well, actually, Alan was here yesterday, and Lori unfortunately is just arriving, so she's sort of coming in here cold.
MR. BLAIR: Alan, have you had a chance to give a little big of feedback to Lori about the testimony that we heard yesterday?
DR. ZUCKERMAN: Yes.
MR. BLAIR: Didn't want her to be blindsided about the comments and concerns about PKI that we heard.
DR. ZUCKERMAN: Yes, we talked last night and I shared my notes on several of the sessions, some of which I listened to on the Internet.
AGENDA ITEM: Presentation – E-Signature: Standards Development Perspective – DR. ZUCKERMAN
DR. ZUCKERMAN: Again, I wanted to thank the Committee for this opportunity to testify and especially thank Lori and ASTM for sharing some time with me to bring a physician perspective to this hearing directly at the table rather than at the open microphone.
It's very appropriate, because over the last year, physicians' professional societies like American Academy of Family Physicians, American Academy of Pediatrics, American College of Physicians have become very actively involved in the work of standards development organizations such as ASTM, NCPDP and HL7. I work actively actually with working groups on both, but my connection with NCPDP has nothing to do with digital signature.
I'm speaking today really, I'm basing my personal experience as a teacher of medical informatics and a practicing physician who has represented AAP to ASTM. You've heard a great deal at these hearings about the potential cost of requiring digital signature, and what I would like to do is to introduce the notion that there are very real potential costs of not requiring digital signature on prescriptions. This is an issue that is not about security hysteria or about HIPAA regulatory compliance; it's really about physician workflow and it does have real impact on the American health care system.
Physicians who know about digital signature, and I consider this technology among the basic sciences of medicine and teach it to my first year medical students, support its use and understand the need for message integrity, authentication, and non-repudiation of clinical documents, particularly those that pass through many hands and many institutions. That's why the American Academy of Family Practice has endorsed the use of this technology as a policy on clinical documents.
Physicians who do not know about digital signature are indeed well=versed in the weaknesses and important limitations of current signature of clinical documents, which is something that's easily demonstrated in any health care institution.
A prescription is essentially a permanent clinical document and not a momentary blip on the Internet. Many years ago, this was brought painfully to my attention when I was involved in a malpractice case involving complications suffered by a young child who was unintentionally given a codeine-containing cough medicine. And of course, the case involved around whether this was an error in prescribing or an error in dispensing and whether some of the damages could be linked to the medication.
Message integrity and non-repudiation are real concepts to physicians and they're essentially not addressed by the use of SSL or DES encryption.
I've also had the very unpleasant experience of having a nurse borrow my DEA number and name to indulge in substance abuse that was fortunately quickly detected by an alert pharmacist. Authentication and identity theft are also concepts that are deeply appreciated by physicians who are actually not pleased by the growing practice of pharmacies to use DEA numbers for physician identification and verification of telephone prescriptions and non-prescribed substances.
I've also had patients add a zero to the quantity dispensed on a prescription and seen my colleagues entertained by electronic signature images on computer-generated fax prescriptions but remain very realistic about the limitations of this approach in a world where they're daily confronted with documents that are labeled "electronically signed without being read." In practice of medicine, electronic signature may actually not hold up in court regardless of what the E-SIGN act says and some of the JCAHO regulations on e-signature have in fact shown that in specific court cases.
Patients also stand to benefit from humane and cost-effective use of digital signature to allow electronic controlled substance prescribing. We talk about controlled substances; of course, we should be thinking about things like Ritalin and not OxyContin. Attention Deficit disorders today are the most common chronic diseases among children and long-term follow-up studies show how difficult it is to maintain medication over several years and you can't prescribe more than 30 days, can't use a fax, can't use the telephone, and can't use electronic prescribing.
My patients and families who are coping with ADHD repeatedly request and embrace the kind of benefits that would come in their lives from electronic prescribing that is unlikely to be realized without the use of digital signature.
We must also recognize that the Institute of Medicine and many others have identified security concerns as one of the major barriers to the adoption of health information –
MR. BLAIR: Could I just ask a question because yesterday I confused PKI with digital signatures. Are you using them synonymously or is there a difference? I just want to make sure that as you keep referring to digital signatures that I know what you're talking about.
DR. ZUCKERMAN: Digital signature is an encryption technology for assuring message integrity, third party authentication of the server, and non-repudiation of the signature. It is usually accomplished through some form of public key encryption. So if there are other ways to achieve a digital signature, I would be happy to embrace them. It is the integrity, third party authentication, non-repudiation that are the essential characteristics.
Again, physicians, particularly in the primary care specialties such as internal medicine, pediatrics and family medicine, face very serious constraints that limit their ability to benefit from digital signature technology because of the constraints on their time and resources.
The fear that digital signature could severely damage the dissemination of electronic prescribing is very real and very well justified, but I feel it must be addressed not by abandoning the core functionality but instead by setting constraints on the monetary and time costs of the specific technical implementations of digital signature.
When office visits take only 12 to 15 minutes, we cannot add an additional two or three minutes, but we might be able to tolerate 15 seconds. We cannot add $100 or $200 of additional cost to the annual direct to physicians of electronic prescribing; we might tolerate $5 or $10, particularly if we attempt to include it in controlled substance registration. Essentially, we must set performance criteria and metrics for digital signature that can reduce the burden of the implementation.
We also have many options in implementation that may make it easier to make digital signature work, although they compromise ideals of security. One of the first things we must do is select a method to carry the private key used in signature. Now, conventional practice would say we should be using a smart card or a token.
We also need a method to activate the use of the signature and special signature passwords have some merits for use rather than biometrics. We actually could place the private keys of individual physicians in escrow with their e-prescribing vendor with serious criminal penalties for abuse and allow release and use of those keys on conventional signature and have a totally transparent use of e-prescribing that would not visibly change the way physicians are practicing.
We also have many options in the way we might separate person authentication from credential authentication, thus allowing the use of any authentication certificate, including vendor-issued certificates, as long as there's cross-recognitions so physicians don't need more than one certificate.
We also heard yesterday about the use of Web services for validating expired security certificates and invalid credit card. We could apply the same instantaneous Web query to validate a physician's DEA number and current license to prescribe.
Over several years now, I've explored many biometric technologies including fingerprint, iris, and a dynamic signature, for control of digital signature and I conclude that it's simply not ready or affordable for use today but is likely to be there at some time in the future. Ultrasound fingerprint readers are an ideal technology for this but simply unaffordable and not portable for physicians who do much of their prescribing from PDAs and cell phones.
Iris technology is extremely accurate, but we don't have auto-focus cameras and auto-scanning devices to limit the amount of time it takes to capture an image. But every single biometric has some rate of failure to enroll that requires an alternative backup technology to be present for some percentage of those using it. Yet, a good password, perhaps with a smart card token, is more than adequate and far better than what we're doing today in the area of signature of documents.
Before we abandon the digital signature prescriptions, we must also consider the powerful educational opportunity we have to introduce a technology that could be used with other clinical documents such as laboratory reports, discharge summaries, and physician communications that could benefit in the future from technologies being piloted today on e-prescribing.
In conclusion, I want to offer that we need the message integrity, third party authentication, and non-repudiation that digital signature can provide, but our implementations must be creative, cost-effective, and appropriate to the level of security risk. Any improvement over what we do today will be a substantial improvement in the risks of prescription security we now endure.
But our greatest need in the next six to 12 months are real world demonstrations and evaluations of realistic approaches to using digital signature so that we can make informed regulatory decisions based on fact and not on speculation. Thank you.
DR. COHN: Alan, thank you. Lori?
AGENDA ITEM: Presentation – E-Signature: Standards Development Perspective – MS. REED-FOURQUET
MS. REED-FOURQUET: I'm Lori Reed-Fourquet, and I'm going to go through the list of standards that I'm involved with because, although I was invited to this Committee through ASTM, I also participate in a number of others, and within those other committees, we are discussing the same topics that I'm presenting here.
I am the Co-Chair of E31.20 Health Information Security and Privacy for ASTM and the Vice-Convener of ISO TC215 Health Informatics Working Group 4 on Security. I'm a member of the IHE IT Infrastructure Committee, a member of the HIMSS Standards Task Force, and a member of the newly formed HL7 Electronic Health Record Technical Committee Expert Panel on Security and Privacy Functions.
So, we need signatures, and particularly in electronic prescribing, to prove that the author or the sender of a document is the one that he claims to be. We need to identify their identity when they do the signing. We also need to carry along their credentials.
We need to prove that the writing and sending of the document is something that the individual is consenting with. We need to prove that the content has not changed and it is complete. It is an integrity requirement. We need to be able to enable moving from a paper-oriented world into en electronic world, an e-document.
Standards for the health care signature – the components are the signature creation. We have to authenticate the signer's identity. We need to present the information to be signed to that individual. We need to capture the signer's approval. We need to construct the logical manifestation of the signed signature in an electronic format.
Signature verification at the other end – the relying party needs to be able to verify the integrity of the record and the authenticated attributes that may be associated with the signed document. We need verification of the identity of the signer.
General properties, based on our standards for health care signatures – we need attestation, such that the user agrees to be bound by signatures.
We need uniqueness; the signature must be bound to an individual and not shared.
Continuity of signatures – signature verification will not require the disclosure of any confidential materials such as biometric content used to create the signature.
Fidelity – we need a logical manifestation that captures the signer's intent, especially when what is presented to that individual may differ somewhat from the electronic coding that is actually being signed.
Integrity – the information that is signed will not change in transit.
And secure user authentication – the reliable binding of the individual to that signature.
Among the logical properties that we need are multiple signers. In health care at least, you may have to have multiple parties signing different parts of the document.
Signature attributes – we need to be able to attach attributes to the signature such as their credentials, their time stamps, the purpose and intent of the signature.
Supplemental properties – we need to look at independent verifiability. We need to be able to verify in the absence of the system that generated the signature that the signature and the intention is still intact.
We need non-repudiation, proof that only the signer could have created the signed document, particularly in legal aspects.
Persistence – the ability to preserve the signature over time.
Transportability – the signed document can be transmitted to another system while maintaining the integrity of the document and the signature attributes.
Specific to e-prescribing, the types of security risks we need to address – in particular is impersonation. This might be conducted through password theft. Password theft itself may be conducted through observing the individual putting their password into the computer. Interception of the key strokes from the input of the password. Auto-complete functions, particularly in some of the mobile devices, can inadvertently disclose a password.
Poor password protection is very common, particularly since we may have many systems to which we need to remember the passwords, too many to protect, and in order to remember, often they're written down. They may be stored in unprotected files. They may be using the same password in multiple locations. They may have a tendency to use favorite passwords and then they become guessable by those that know the individual.
The ability to spoof the credentialing process is another security risk. Theft of a system-stored credential, for instance, a software certificate or a software-stored signature that one might apply to a document without the owner of the signature knowing. And being able to force or trick the individual into unintentionally signing something.
Additional security risks in e-prescribing would be the misrepresentation of credentials; information changing in transit, which might specifically be modifications in dose or quantity; controlled and abused substances – there could be an increase in drug diversion, lack of accountability, fraud.
There is a high incentive to break the security when dealing with controlled substances. There is a potential for harmful effects, including death by suicide, homicide, overdose, et cetera. There is a very strong need for non-repudiation within the accountability of the clinician who has very strong power behind their prescribing credentials.
Patient safety is also a potential issue for non-controlled substances that may have clinical impact on the patient. It is not the same risk perhaps for antibiotics and some of those therapeutics as there is for controlled substances and so there may be a two-tiered approach here.
The e-prescribing requirements would include non-repudiation for controlled substances, interoperability across unbounded systems, high assurance user authentication and communication of the credential information such as the DEA number along with the signature.
Electronic signatures in medicine should not be overlooked in taking a look at what we need for e-prescribing. High-risk clinical orders must be accommodated as we move into e-health systems and do please beware in considering this topic separately from e-prescribing so that it does not needlessly encourage non-interoperable systems. A clinician should be able to leverage digital signature technology for other electronic signature acts. Some may have greater risks, some may have lower risk, but to force multiple signature technologies, when one has gone to the highest approved, would be difficult.
We need migration; we need to perhaps enable with the low-risk opportunity and set of criteria for expanding those opportunities.We need an interoperability for e-prescribing in particular. It costs more to process workflow in the lack of interoperability such as examining a wet signature. As long as we depend on hands-on, out-of-band data authentication processes performed by the pharmacist, we have a real barrier to cost-effectiveness.
Interoperability of secure clinical systems and prescribing systems is important to the continued growth of electronic prescribing.
Mobile patients require and use options beyond the sub-community model.
The signature – what does it prove and what is its value? If a public and private key pair is associated with an identified signer, a digital signature by the private key can effectively support the requirements of attestation, uniqueness, integrity, secure user authentication, and specifically digital signatures can enable continuity of signature, persistence, independent verifiability, non-repudiation, transportability and interoperability.
Digital signatures can enable high-assurance authentication and may reduce the need for auditing and other monitoring processes that might otherwise be required to protect the multiple opportunity points of intrusion and impersonation within the system.
Currently, there are no recognized security techniques that provide the security service of non- repudiation in an open network environment other than digital signature-based techniques.
The protected security context and signature generation mechanism itself may be either totally in the control of the user/organization or else provided as an application service by the health care organization.
The degree of the signature's non-repudiation is impacted by the extent to which the signer maintains control over the protected security context. Where the control of the security context is subject to the health care organization's administrative processes, the signer can repudiate the signature on the basis of a failure of control over those administrative processes.
Digital signatures associated with trust-based entity registries can provide a higher level of assurance of practitioner identity and intent, can provide and enable a one-time registration process, can provide the same registry and registry interfaces used to support automated exchange of other health care documents and other health care messages.
Vendors can share authentication information infrastructures without compromising propriety value adds, and digital signatures eliminate redundant, proprietary implementations of infrastructure-level system components.
Trust in a digital signature can be obtained when a private key is kept secret. The storing of the private keys in a secure, tamper-proof device such as a smart card is important so that the owner of the signature maintains control over their signature.
When the association between a public key and the key holder is guaranteed, a trusted third party should guarantee the link between a key holder and their public key.
There are multiple trust models. A PKI was asked earlier if that is a requirement for enabling a digital signature, and it is not. There is a direct trust model which would be an out of band verification of a certificate binding to the user signature key.
This does require manual processing of agreements for using the specified key for user intended signature. It requires manual processing in key compromise. But this is a method that is currently used by the FDA in the drug approval process described by 21CFR Part 11.
There is also a closed community trust model whereby the signer and the relying party may be in the same enterprise or the same controlled environment, these bounded communities where all communication parties are pre-determined. This unfortunately has fragmentation and limited interoperability across those bounded environments and upon crossing the boundary of a closed community of trust, you must rely on manual and secondary systems in order to obtain trust of the signature.
Mail-order pharmacies, Web-based approaches, portable patient record-based approaches and other new pharmacy and e-business-e-health approaches to workflow automation, patient choice, quality of care and cost control cannot rely on closed boundary options.
Consumers of health care and prescriptions are not within bounded communities; they cross these communities.
We need to eliminate the requirement for a pharmacist to have personal knowledge of the practitioner's prescribing patterns. We can use the same interoperability framework used for other documents and messaging. And we need to work toward national interoperability rather than sub-community interoperability.
The PKI trust model is typically based on an infrastructure but this does not need to be a national infrastructure. There are a number of countries out there that are implementing national infrastructures and it is a very valuable approach.
It can be done through regional infrastructures, however. It can be done through private sector infrastructures. It can be overlapping infrastructures. And it could be at the enterprise level.
Standard health informatic PKI policies enable interoperability across multiple PKI environments. This is seen through federal bridge approaches. Cross-certification is an approach from certification authority to certification authority or trust structure to trust structure.
The applications and the enterprise – trust can be enabled at the application level or at the enterprise level for those multiple PKIs that may be trusted. At the individual level, it can be enabled. And we have standards in place that support policies that we can enable this cross-trust without a great degree of examining multiple policies.
PKI has increased prevalence in technology today. We have the growing experience in PKI both in health care and in the technology industry in general. We have off-the-shelf product support from Microsoft, Sun, Novell, Lotus and many others.
We have application support today for signed and encrypted emails, for VPNs based on digital certificate technology, for Web-based authentication using these digital certificates, for database authentication in signatures.
There are numerous software developer toolkits available. These APIs are available for multiple platforms to enable the application vendors to conduct signing, signature verification, PKCS11 support, which is talking to the smart card in a cryptographic manner.
PKI increased technology prevalence is also within the industry. IHE is adding profiling support for PKI and for digital signatures within their existing and new profiles. This itself will stimulate the health information system vendor adoption of the supporting technology.
HIMSS is supportive of propagating the digital signature technology and the uptake of security in the industry.
International health informatics PKI standards have been defined and are being adopted around the world as each of the countries gropes with the same types of health information security issues we have here.
Community demonstration projects are out there that are beginning to incorporate and test the PKI and digital certificate technology.
And as we've heard from Dr. Zuckerman, there is increased physician acceptance of the technology and the approaches.
So how many keys do have? There seems to be quite a bit of concern about how many key chains we will have, how many digital certificates we'll have. How many keys do we need to manage?
We have defined in our standards that we should minimally have an encryption key and a signature key, and this is because for the encryption key, we need to enable key escrow. Key escrow is a mechanism to back up data, and for health information, we need to protect the health information retention should that information be encrypted. An individual who is also a practitioner may very well want to separate their personal use keys from their professional use keys; because the escrow requirement for health care, they may wish to control the escrow with their personal key.
Secure tunneling keys which do not impact the individual necessarily would be for big systems. Organization keys would be available for your communication to an organization.
The signing key, separate from the encryption key, is intended for non-repudiation. There should be no key escrow; this does not preclude high SIPS Level 3 access to the keys on a hosted system.
Strong key protection, however, is critical to a signing key in order to accommodate non-repudiation.
It is not necessary to have a separate key for each certificate created. You can make a new certificate with the same key to multiple authorities. Many keys can be stored on a single smart card or chip, so even when you do use multiple keys for multiple purposes or multiple organizations, it does mean that you're walking with numerous cards or tokens on a key chain.
Attributes for credential certificates have been defined within our international standards and are important for the conduct of health care credentials and the assurance of health care credentials.
Health care transactions and security – it provides an assurance of the individual's identity, and we also need an assurance of clinical and regulatory credentials when we're conducting health care transactions.
We have identity certificates for certificate types and attribute certificate. These can be bound in a single certificate, as we've defined in our international and national standards on PKI whereby we attest to the individual's identity and their health care credential, typically their license, and we put that information in the same certificate. This approach is commercially available and is being conducted today.
Attribute certificates are typically associated with an identity certificate. They are, while commercially available, highly limited, and experience with them is also limited, but there is great promise for using these in the future.
Identity and attribute key management – they may be bound to a single organization being both an attribute authority, as we call it, and an identity certification authority. The could be de-coupled whereby the identity authority is different than the attribute authority. Or they could be missed – it doesn't mean that you have to go with one approach or the other.
Certificate types – we have the public key certificate. This uniquely links a public key to a person or an organization issued by a trusted party called a certification authority as opposed to an attribute certificate which links the attribute characteristics to a person or his public key. Similar techniques are used for the attribute certificate as for the public key certificate. They're issued by a trusted party, in this case called the attribute authority.
This diagram is borrowed from the Belgian proposal for application of digital signatures in health care, a very similar approach being considered for management of health credentials there. They will have a national identity card with a public key certificate and they will issue attribute certificates for the health care credentials.
Within that model, they have also described an approach for signing the document and attaching the attribute certificates associated with the individual and also an approach for verification of the signature that has the attribute certificate attached to the document.
Key protection we've discussed as requiring a tamper-resistant media. We need the keys to be portable, protected by a PIN or biometric. If it's on a card, we can enable a single card through multiple certificate and key storage. We can allow the use of private keys for requests to multiple certificate authorities and essentially create a virtual attribute certificate even if the technology for attribute certificates themselves are not available today.
Smart cards – there is a growing a number of form factors for tamper-resistant storage of keys. There's the classic smart card that we've seen and looks very much like your credit card. There's a combination smart card and proximity reader which is good for an institutional level where they can also make that an ID badge and incorporate some of the other functionalities of e-wallet.
There's the USB-readable token which is much like the USB portable drive. There is also emerging and existing mobile technology support for chips and readers with SDIO interfaces, compact flash interfaces, sleeves for PDAs, GSM and CDMA chips for wireless communications.
And the capacity of these technologies are increasing, enabling us to store more certificates or keys on those cards and potentially storing other application features on those cards and data. The cost of this technology is coming down as well.
We have a number of ANSI-accredited balloted and health informatics security standards which support digital signature. The ISO/TC has generated three documents for health informatics public key infrastructure. This is technical specification 17090. It has three parts, an overview, a specification, and a policy component. This is in the process of being converted into a full international standard and this is the one that is being considered for adoption around the world.
ISO/TC 215 also has the technical specification approved this last week, 21091, for health informatics directory services for security, communications, and identifications of professionals and patients.
ISO/TC 215 also has a draft technical specification in three parts for privilege management and access control, and this is being harmonized with efforts in HL7 and ASTM.
ASTM has E1762. The original document was from 1995; it is in the process of being updated. Originally, it was a standard guide for the authentication of health care information and it's under revision as a specification for authentication of health care information using electronic signatures.
Within this document, we discussed the requirements of signatures and we discussed where it is appropriate to have strong approaches and other technology approaches.
ASTM has E2084, standard specification for the authentication of health care information using digital signatures. We also have ASTM E2212, which is a standard practice for health care certificate policy, which has been harmonized with the ISO health informatics public key infrastructure.
DICOM has Supplement 41 and there is also ISO/IEC 15408.
Of course, there's the supporting IETF/RFCs regarding X.509 PKIX and S/MIME and IHE, interconnecting the health care enterprise, is incorporating digital signature support and PKI support into its profile on PWP specific for pharmacy. Perhaps this will provide the directory for the pharmacy contact information. And the XDS potentially can be used for e-prescribing if has agreed upon documents for medication lists.
PDQ could be used to obtain the demographics and even insurance.
And this year we're looking at a new profile development entitled Digital Signatures for Attestation and Authorization.
There is also the Enterprise User Authentication.
There is quite a bit of cooperation among the SDOs and the industry in this area. Multiple individuals represented in multiple SDOs for the health information security are on these committees from ASTM, ISO, HL7, IETF, DICOM. HIMSS urges and supports the adoption of the standards that will lead to digital signature. There's physician participation in these groups, and the DEA has and will continue to participate and interface.
Secure e-prescribing test beds for health informatics security standards are beginning to form.
We have local information infrastructure community test beds and grassroots initiatives in Connecticut – Danbury Health Systems, Middlesex Community, and we are in discussion with others to establish a secure e-prescribing pilot based on these health informatics security standards.
The Community Foundation of Central Florida similarly will be incorporating these health informatics security standards with a continuity of care record community profile.
We have health informatics standards. We're in need of funding for these projects and we recommend that these types of pilots and demonstrations of health informatics standards be part of the pilot testing in support of MMA.
Secure e-prescribing stakeholders need to be involved in all of these – the health and pharmacy regulators, the DEA, the drug controls, the pharmacy commissions, the state departments of health, clinicians, pharmacists, patients, insurance companies, drug manufacturers, industry vendors, industry standard development organizations.
We would like to recommend that we create a collaborative road map with buy-in from multiple players including health information security standards, IHE, with industry support from HIMSS, recognize the end objectives and the risks of all stakeholders and define reasonable steps get there, including the objectives of law enforcement, the objectives of clinical care providers, objectives of pharmacies, objectives of insurers.
We recommend that we do not prevent the momentum of enabling application, communication and workflow progress for non-controlled and low-risk prescription drugs as we have quite a momentum already underway in e-prescribing where there is low risk.
Do not, though, preclude the incorporation of digital signature for those that adopt the technology for other security functionality in their environments.
Encourage the interoperability with electronic medical record systems, not just at the data level but the user interface level and electronic medical records security approaches.
Provide funding for standards development, for test beds of health information security standard pilots and demonstrations, fund progress and enhancement of the supporting infrastructure technologies, assess the efficacy of the test bed deployments, and roll-out nationally. Thank you.
DR. COHN: Lori, thank you very much, and thank you, Alan, for very useful additional testimony.
Questions, Answers and Comments
Let me just start off and ask others for questions. I just obviously was listening to both of you and I just want to make sure that I think I'm hearing right. I think both of you are sort of indicating that PKI is very promising and is probably where we should be going. I'm not sure that I heard either of you say that either of you would recommend starting in January of 2006 that everyone immediately implement PKI. I think I was hearing that both of you felt that there needed to be some demonstrations, particularly some pilots, to make sure that this can scale and that the standards really work as intended and all of this. Is this sort of what I'm hearing? I think maybe what I'm hearing – I guess I should ask all of three of you; is that sort of what everybody is saying?
MS. REED-FOURQUET: Yes, I would recommend that we begin with the pilots, we make sure that all the concerns are addressed, that we can demonstrate that it is successful. We don't necessarily have to wait until 2006; we have these communities that are ready now to begin and to begin their architectures and getting their communities together, but yes, begin with pilots and test it and deploy it.
DR. ZUCKERMAN: There's a possibility of being ready in January, 2006. We can't make statement today. There's too many unknowns, too many risks of causing serious damage both to the health care industry and the e-prescribing component of that simply because there are so many alternate technologies.
A lot of us have a lot of hope in the W3C consortiums, XML signature approach but we still haven't moved all of e-prescribing into XML. We still haven't heard enough from the DEA to really know what the bar will be set at. And we still have many serious state and other coordination issues.
DR. COHN: Lynne?
MS. GILBERTSON: I think, to tag onto what Dr. Zuckerman said, but my answer would probably be no, that there's enough that's already thought to be for January, 2006, and it doesn't appear that this is as well along as it could be. Future? Possibly. But I think it'd be recommendation that it not be one for 1-2006.
The other is, once again on the pilots, to clearly state what problems we're trying to solve so that we can measure what it is we're fixing.
DR. COHN: Okay.
DR. ZUCKERMAN: I think that what we can say with a certainty, though, if we don't try, we're never going to get there. We have to get out and attempt to use these technologies or we're going to be in the same place five years from now. We need to begin to use them. We need to have an incentive and a sense of urgency.
DR. COHN: Okay. Steve, did you have a question or are you –
DR. STEINDEL: Yes, I have a comment and a question and unfortunately I have to get to another meeting in the next few minutes, so please forgive me; I'm going to be like the panda: Eat, shoot and leave.
I think it was a very interesting discussion and I think there's two components to the discussion. And one component is the need for security and maybe PKI et cetera in the world of the electronic medical record and in the world of data at rest and maybe in the world where removing electronic medical record information from point to point. I think there's a different burden on non-repudiation, security, encryption and privacy in that environment than in the environment where we're talking about a single point in time transaction that's going from one place to another and really has a limited lifetime in the transport phase, because the actual prescription itself, from a medical records point of view, what caused this generation et cetera, would be in the electronic medical records system, assuming that was used. And that, I'm talking about, is a different environment and we can talk about different encryption technology et cetera there.
And likewise, we're talking about a different security exists on the receiving pharmacy side and perhaps the intermediary side. They have a different burden with the data at rest.
But the action e-prescription itself is a one-time transaction that's sent from one point to another point source perhaps through intermediaries, and we've heard a lot in the last couple of days about how weaker security systems that are being used today are effective for that limited time transaction.
And I want some sense of why we should think differently, based on what you have said. Now notice, I'm not saying anything about not using the stronger encryption which I totally agree is something that we need to look at and we need to discuss, we need to think about, and probably will be the route that we have to take with the data at rest.
And I'm also implying that perhaps we need it in data in motion where the data is of much more intensity than it is with the prescription itself.
So please comment on that because I think that's a very important point of introducing a PKI system for e-prescribing and not a PKI system for medical information. And I likewise agree that maybe five or 10 years if we have a PKI system for medical information and have a lot of experience in it, it will be easy to roll the e-prescribing environment into that, but as you two acknowledge, well, it's not ready for prime time yet. I'd like some comment on that.
MS. REED-FOURQUET: I will start backwards. The ready for prime time is more a matter of any given community establishing an e-health interoperability more so than whether or not digital certificate technology is available.
DR. STEINDEL: I accept that point. This is not a technology issue; this is an implementation issue.
MS. REED-FOURQUET: Yes, and we have the same issue in looking at the national health information infrastructure.
The encryption technology happens to be able to use the same infrastructure for conducting encryption as it can for attestation to the content of the information and accountability to the content of the information.
And it is not the encryption that is of concern so much because that can certainly be accomplished through other mechanisms and other virtual private networks and technologies and whatnot. It is the accountability behind that signature and somebody to be able to non-repudiate that that transaction was intended and that somebody who acted on the transaction received did so knowing the origin and the credentials of the sender.
DR. STEINDEL: But we have heard the last two days is from the e-prescribing community there are methods to do that, which it can be done outside of digital signature that they are comfortable with, with time-tested ways.
DR. ZUCKERMAN: I have a great deal of difficulty n three of the things that you're saying that I think are wrong assumptions.
One is the one-time point-to-point assumption. A lot of e-prescribing is not done during continuous connection, is not immediately transferred. The ultimate recipient pharmacy is determined more by the patient than by the physician who actually writes the prescription.
The second issue is that others are going to lead and we can follow. I think e-prescribing is absolutely in the minds of most physicians. The poster child for e-signature – this is the place where it can and will happen, if it's going to. So I think to wait for others to go first is a mistake because others are waiting for us to go first because this is the area that seems easiest to do and it has the most incentive. Comparing this to a laboratory report, to a medical record, this is something that's doable.
And the third thing – the relationship of the e-prescription to the medical record. A great deal of e-prescribing, much of the success of e-prescribing, because it's taking place outside of medical record applications is the users of e-prescribing far outnumber the users of electronic medical records.
Back in 1975, I did a study documenting the number of prescriptions that never make it into manual medical records, and this is something that we're always going to live with. The reality is that the e-prescribing records are our best and most complete records of prescriptions.
Starting next January, JCAHO wants every hospital admission to have a record of medication histories that's going to come out of the e-prescribing system. That's because we have so many failures in our medical records system and failures to transfer information.
So I think this is an important opportunity to lead, not to follow others.
MR. REYNOLDS: Stan? Steve, are you done?
DR. STEINDEL: I probably have some follow-up on this when we have Committee discussion.
MR. REYNOLDS: Okay. Stan?
DR. HUFF: Could you address the usual kinds of costs people are seeing in the prototype experiments they're seeing, the per-person costs or some aggregate system cost to implement digital signatures?
MS. REED-FOURQUET: I'm not sure how best to give you figures. I can tell you that the costs have come down tremendously from where they were several years ago, specifically four or five years ago when they first started attempting to use digital certificates in health care. It is probably about one-quarter of the cost at this point in time.
DR. HUFF: And what was it estimated at back then?
MS. REED-FOURQUET: I don't have figures for what it was estimated at. I know what the drop has been. So,
for instance, a smart card reader when they first were being used – actually they're about $12 now and they were at about $45 to $60 before, depending on quantities.
The certificates themselves have come down from prior they were several hundred dollars and now they're certainly well under $100, depending on how it's deployed and who's deploying it.
The requirement to have a separate card and reader is now condensing into the single device which has both the reader and the chip in it, so you're not needing to provision as much hardware on the deployment.
DR. ZUCKERMAN: I think that we still have to think of numbers that can approach, at least in the past $200 to $250, it'll be an achievement to keep it under $100, and we need to distribute that cost and attempt to leverage it against other entities. Hospitals are getting under $50. But this is not a trivial cost.
DR. HUFF: Second question. I think everyone here would agree that digital signatures offer potential advantages, without question.
And what I think is in my mind and many people's mind is at what cost and when, and in particular, for instance, I would say, do you know of any studies, for instance, that have shown decreased frauds and abuse by the use of digital signatures within medicine so that we can offset the costs that we're conjecturing for actual benefit?
In other words, it could be stronger but in fact it's like every tradeoff in medicine; there's some balance in costs versus the benefit that we gain. And so without question, it's stronger. At what cost and are there studies that demonstrate what the real savings would be in better conviction rate of fraud or anything like that?
DR. ZUCKERMAN: We clearly do not have that today. We have some experience in the Partners HealthCare system that's shown the lack of economic effectiveness of biometric. The VA is getting close to implementing some digital signature; I don't know the details of that. It may well be that the VA may be our best source of some of that data if they're able to do it.
That's why I say we need studies, we need facts. We can't today prove that this technology is going to be cost-effective, and therefore we need to make tradeoffs between risk and quality. This is why I feel it is worth trying to use the technology without the smart card. If the readers and the cards are too expensive, we could allow our e-prescribing vendors to hold those private keys in escrow and control them by the same kind of passwords we have today. But at least we will be adding the signature data to the record.
There's a lot we need to learn. We don't have hard data today about what the improvements will be because no one has had the courage to use this outside of a few individual institutions and applications.
MS. REED-FOURQUET: There may be some data available out of Australia where they have converted PKI-based systems as an infrastructure. I believe it was a few years ago and they've been completely electronic for approximately two years. I don't know –
DR. HUFF: Do you know a citation, or how would one find out information?
MS. REED-FOURQUET: I don't know of a citation in particular, but I do have colleagues there that would know if there are publications.
DR. HUFF: Another question. I mean, since you're one of the few physicians that we've had actually testify, how would you assess the general level of knowledge in the usual physician on the street, practicing physician, in terms of distinguishing the things that we've been talking about and their knowledge and desire for such things? In particular, the ability to distinguish between digital signature, electronic signature, PK – you know, private/public keys, certificates. What would you gauge is the general level of knowledge and ability to make a judgment and have a desire for this kind of technology in their systems?
DR. ZUCKERMAN: The knowledge is extremely low. The desire specifically is not there. The desire for some of the capabilities is there.
But education is changing. A few weeks ago, I spoke to the American Academy of Pediatrics national meeting, spoke for an hour in the lab about this technology, did present some of these differences, and people are listening.
When they come to town next year, we hope to have hands-on laboratories to teach people and give them the opportunity to use these technologies. That's one of the problems with January. We have a long way to go in education, and in fact, as part of our national framework and national strategy for health information technology, we need to begin educating physicians, and that education has to occur at all levels.
It isn't there today. There's concern for security, there's awareness that electronic signature is not going to be adequate. The knowledge of the alternatives, the willingness to engage, and the experience in seeing it used, using it themselves, needs to become part of our continuing medical education.
MR. REYNOLDS: Jeff, did you have a question?
MR. BLAIR: Yes, I was looking for Simon's guidance here because Lori, I don't know if you knew, but we always identify any potential conflict of interest, and since Peter Waegemann is my employer and he's Chair of ASTM, there's a bias and I want to make sure that I don't do anything that is inappropriate.
I think this is a neutral question, just for information, and that is, you indicated that you're working with Connecticut and Florida on demonstration projects and that you had asked to be part of the MMA demos and you thought that those might fold into the MMA demonstration projects, so my questions are: Is the demonstration project that you have in Connecticut and/or Florida, is that e-signature – excuse me; e-prescription? And if it is e-prescription, are you using NCPDP SCRIPT in those demonstration projects or is it something else?
MS. REED-FOURQUET: I'll start with answering in the state of Connecticut. It is very much a grassroots effort. We have the health care communities that are ready and willing to demonstrate to uptake the standards. We have the e-prescribing vendors. Specifically, we have HealthRamp and Allscripts and we're talking to others. We're willing to incorporate the digital signature into their application for testing.
We have had some discussions with RxHub and with SureScripts to be able to take some approaches to processing those as value added networks and pass them on to pharmacy.
I've been in discussions with the pharmacy commission, the drug control officer for the state, and the associations in the state to establish the stakeholder involvement.
That one is specific to e-prescribing.
The Danbury health system is also looking at affordable patient record whereby they would very much like to have the patient carry their information from site to site.
In Florida, it is a community-based initiative for a personal health record that is the foundation project. And as part of the personal health records is communications involved with the clinicians and exchange of health information and they would add to that the electronic prescribing component.
This would be using NCPDP SCRIPT format.
MR. REYNOLDS: I have a question. I think I heard during your testimony that minimally you want to make sure that any standard that comes out does not preclude use of PKI at some point.
DR. ZUCKERMAN: That's right, that's correct, right.
MR. REYNOLDS: Any other questions from the
Committee? Maria?
DR. FRIEDMAN: This is for Lori. This gets back to the demonstration projects that you hope to ramp up. You said they weren't funded. What kind of ballpark funding were you looking for?
MS. REED-FOURQUET: That's going to very much depend on the size of the project and it's a little bit of a chicken and egg problem because we could easily do a statewide project. The state has worked together, in Connecticut, that is, before in some leading edge technologies and building a network information infrastructure, which we did back in '94. Yet, without the funding, it's difficult to say that we would do that statewide.
I have a handful of communities and we have vendors who are willing to in kind some of their products but they can't bear the whole burden. And unfortunately, I'm in the process of trying to compute what that funding requirement will be.
MR. REYNOLDS: Any other questions? Thank you very much, all of you.
We're going to take a 15-minute break, till 3:30, and then Simon hopes to be back by then for our discussion.
PARTICIPANT: Open mike.
MR. REYNOLDS: Yes, open mike, and then our discussion, so we'll plan to come back then.
[Break begins at 3:17 p.m. and meeting resumes at 3:42 p.m.]
DR. COHN: Okay, we're getting started here for our last session of the day.
This starts with really the open microphone, and we wanted to offer people an opportunity, who have been sitting here so patiently, if they'd like to come up and make brief statements on any of the subjects being discussed today.
And then I am sure we will gradually transition into just sort of a discussion of what we heard as well as asking questions. I mean, we may ask questions of the experts who are sitting here so gracefully in our panel and otherwise have a conversation as we try to sort of identify sort of what we heard, what we've learned, and next steps.
Please identify yourself, and thank you for coming.
MR. BROOK: Thank you. Richard Brook from ProxyMed. And again, as you know, I've had the privilege and the pleasure of being here on several different occasions.
One of the things I want to get pretty clear is – I believe Mike Simco made comment to it – ProxyMed over the last eight or nine years, or 10 years actually, has done over 19 million electronic transactions between physicians and pharmacies. Not all of them initially were in the NCPDP standard; some were in our proprietary Proxy script standard.
However, the point of abuses could be either at the point of prescribing or at the end result where the pharmacy fills the prescription. We have had nobody ever break into any of our communications after the prescription has left the physician's office to our network and from our network to the pharmacy, to our knowledge.
So, we just want to be clear about whatever processes and procedures have been in place as far as the secure log-ons and whatever issues we had even earlier on with point to point connectivity et cetera.
So, understanding about PKI and really sitting here listening about that, what we have in place today works, and I just want to make sure. And obviously, moving forward with PKI and getting much involved security-wise and getting involved with the DEA, but I just want to be clear about the one thing.
The other part is I believe Harry made a statement yesterday, or it could have been Stan, saying, well – I think it was you had asked somebody about who do you think is the best people or committee to make recommendations about e-prescribing and what's taking place.
After sitting here for the last two years when we first started talking about this, and as MMA has evolved, and this is much, much bigger than MMA, we thought that we'd hear when we made the recommendations to MMA about e-prescribing and how this group, NCVHS was the point people for that.
But you folks have – listening to the questions and being involved with this space for about 10 years – it's really interesting to see how I've sat here and watched all of you evolve, and the questions that are asked and even questions after doing this for 10 years I haven't even thought of.
So you are in such a great position to recommend to the Secretary, and I really believe that you'll do what I think that we have really said, in the best interest of the community pharmacy today as well as physician groups as far as the levels of security that are in place, but just in general, even all the things and seeing the processes and the procedures taking place here has been just a real pleasure for me to be involved. Thank you.
DR. COHN: Well, thank you. Well, I think we'll all smile. Appreciate it –
[Laughter.]
DR. COHN: Until our next set of recommendations, in which case people may not be quite as happy, but we'll see what happens. Actually, anybody have any questions for our last commenter?
DR. WARREN: Yes.
DR. COHN: Yes – actually, I don't think we're going to let you off the hook quite that easily, even though we were smiling just a second ago, but –
DR. WARREN: Yes, I had one, but it was Lori.
DR. COHN: Next one and we can sort of pull Lori in with your question here.
MR. HAAS: I'm not really Lynne. Jim Haas, WebMD. And I also appreciate the opportunity to speak.
One thing that dawned on me as I was listening to the conversation on PKI, and maybe it's only dawning on me and everybody else's sun is already up in the sky, but one of the hallmarks that we've talked about is the patient's freedom and flexibility to choose a pharmacy as being very important to preserve that.
And for all the shortcomings that a paper prescription has, there's nothing quite as flexible as driving around with a piece of paper in your pocket and you can pull into any pharmacy on any corner and if that physician has never written a prescription and it was filled at that pharmacy before, if that patient has never been at that pharmacy before, nevertheless that prescription can be filled, the patient's needs can be taken care of.
Now if you take it one step to the e-prescribing and there is somewhat of a reduction in that flexibility because that choice now is made before the patient leaves the physician's office, so he's not driving down the street; he has to have made that decision so the prescription can be routed. And he's limited to an extent to the prescriptions that are available on the e-prescribing network.
Now, one of the things that Mike Burger talked about was that's the reason that faxing plays an important role in e-prescribing. It increases the size of that network to keep the patient's choice as broad as it can possibly be.
Now, when we move to a PKI, we move to a situation where there really has to be a pre-existing relationship between a specific physician and a specific pharmacy because that pharmacy has to have the key in order to decrypt that message. Or there has to be a way that that can be done in a time that is commensurate with the normal prescription filling process.
In other words, if the patient wants to go to a pharmacy and that pharmacy isn't prepared to handle the transaction from that physician, he may not be able to read that prescription because he doesn't have the key, and he needs to be able to obtain that key so that he can decrypt that prescription and fill it.
DR. COHN: Can I ask a question there? I mean, because you were sort of talking about faxes and all of that and the ability to be there, I presume, under those circumstances, that the value added network would translate it and send it over. Is that correct? They would have the public key.
MR. HAAS: Well, that gets back to the conversation we had before. Is it encrypted from point to point to point or is it encrypted from the inception to the end point?
And I was assuming a model of it was encrypted at the physician and not decrypted until it arrived at the end point, the pharmacy.
DR. COHN: I guess that's something which might have to be explored. I don't have the answer to your question about that, but –
MR. HAAS: I guess I'm asking the question, sure.
DR. COHN: You need to come to a microphone and introduce yourself. We're going to ask you questions anyway, so –
MS. REED-FOURQUET: You're confusing a little bit the encryption component and the signature component. The encryption could be done with PKI, doesn't have to be done with PKI. The PKI's strength here is in the signature.
The signature itself does not encrypt the document. The signature verifies the integrity of the document and its origin and the origin of the signer.
The encryption could happen through a VPN tunnel, it could happen through any other encrypted mechanism. The pharmacy does not have to know in advance the public key of the signer. Typically, the signature is appended with a public key for verification purposes.
So I could send you an encrypted email into your Microsoft package, and as long as you can trust the certification authority, your product already knows how to verify your signature.
DR. COHN: Yes?
DR. ZUCKERMAN: In fact – Alan Zuckerman – PKI actually extends the flexibility in the process considerably over where it is today because of all the information about the prescriber that is on the certificate that either physically travels with the signature or is readily available from a separate source, as was pointed out in the first session yesterday.
I am personally licensed in three different states, here in Maryland, DC and Virginia. I have three
different DEA numbers, I have three different state licenses. Two of the states have their own controlled substance things. If my patients choose to fill that prescription across the river in Virginia, through a PKI architecture my Virginia DEA can be immediately linked to my signature, just as my Maryland DEA could be linked if they choose to fill that prescription in Maryland.
So the beauty of PKI is that all of this information travels with the signer and that's a better situation than what we have today. And furthermore, you can authenticate if those licenses and those DEA numbers are still valid at the time the prescription is being filled.
DR. COHN: Judy, I think you had a question for Lori? Did you want to – since we have her here?
DR. WARREN: Yes. You had talked about pilot projects not only in Connecticut but also in Florida and one of the things I was wondering is do those include this PKI technology and what are your findings, and is it including more than just e-prescribing? Could you just kind of tell us what's happening in the pilots for us to kind of pull it together as a more cohesive piece.
MS. REED-FOURQUET: The pilots are in a planning phase, so I won't say that they are today using it but the one in Florida is a community project. It is for the personal health record and that one will be deploying in the beginning of 2005.
DR. WARREN: Are you going to use PKI in that?
MS. REED-FOURQUET: Yes, that will use PKI and that will be using it for the purposes of patient identification and authentication purposes with the clinicians in the environment.
And the e-prescribing will begin as an alpha pilot in the Connecticut initiative and we will beta it in the Florida initiative.
DR. WARREN: Okay. So right now you don't have any information for us, just that it's being planned to roll out in both of those –
MS. REED-FOURQUET: We're in the planning and architecture phases.
DR. WARREN: In your planning, have you run across anything that we should pay attention to as we're thinking about making recommendations?
MS. REED-FOURQUET: I'm finding a great deal of acceptance and willingness to try the technology and I don't think that we will have barriers to get the pilot going other than trying to get the resources to get the pilots off the ground.
DR. WARREN: Well, I think the resources we'd be interested in, too, because quite a few people have questioned about how much money and resources and things like that some of these technologies will cost.
DR. COHN: Harry, did you have a question? No. Are there any – actually, since we have Lori here, are there any other questions since she's sitting here right now? Okay.
Are there other testifiers in the open session?
MR. BLAIR: I guess I can ask a question here of Lori.
DR. COHN: Don't you want to go to a mike?
MR. BLAIR: I guess I ought to get to the mike.
Lori, what vendors or networks have or are working with you with respect to either of the pilot tests in using PKI technology?
MS. REED-FOURQUET: I have a long list of vendors; I'm afraid I might some of them out. But these include Novell, RSA, Custodix, AET Europe, HealthRamp potentially, Allscripts potentially, Danbury Health Systems, Middlesex Hospital, Community Foundation of Central Florida, Dell, and I should have my notes in front of me because I have a list of approximately 20. Okay?
DR. COHN: If you would send it to us, it would be great.
MS. REED-FOURQUET: Okay, I will do that.
DR. COHN: Other questions? No? Okay.
AGENDA ITEM: Subcommittee Discussion – DR. COHN, Chair
Well, let's transition then into sort of talking about what we've heard, and I think probably most importantly at this point, sort of next steps in relationship to all of this, and I know Stan's been taking very good notes, as has Margaret. But I guess, I mean, even without the notes, I guess we sort of need to begin to think about how it is we want to – I mean, both think about this one and the open questions that we may wish to explore.
Now – and maybe I'll start out with just a couple of broad statements that I will say posit based on the testimony that I heard and sort of see if any of this makes sense. And Stan, did you have some broad statements you want to start with? Please.
DR. HUFF: I wanted to ask stupid questions first.
DR. COHN: Oh, please, ask stupid questions first.
DR. HUFF: I just wanted to frame it as: In terms of the legislation, what are we charged with in terms of what we're supposed to recommend to the Secretary about this subject?
DR. COHN: Okay. Well, let's start with that.
Yes, first of all, this is really a continuation of our previous set of recommendations, so, I mean, we'll start with the narrow world and then we'll talk about the wider world, but I won't describe e-prescribing as a narrow world, but there's the very specific use case of e-prescribing.
If you remember, in our first set of recommendations, we talked about things that would be useful or necessary or helpful and are ready for 2006. We talked about things that needed to be piloted or tested in 2006. Some things we said are so firm – those were foundational standards, if you remember the term we used.
DR. HUFF: Yes, and if the Secretary adopts them as foundational standards, what does that mean?
DR. COHN: Well, that means that we'd have to talk to Maria, but the question really was: Are there things that might really be ready for 2006? Maria, do you want to finish up that sentence?
DR. FRIEDMAN: The foundational standards were ones that – and I forget exactly the language of the statute – but had such already broad industry acceptance that they didn't need to be piloted, and those were the ones that we proposed.
MR. BLAIR: My understanding of foundational standards was that these are standards which no matter what else we do, and no matter what other standards we might select, these are the foundations. NCPDP SCRIPT was a foundation and I guess AST X12, 270/271 was a foundation.
And we might indicate that there might be other messages that might be added to them, there might be other terminologies that might be used with them, but these were the foundation ones.
So, in short, even if there were other things we would test, we still had to go back to these foundational standards to test them with whatever was going to be tested. Now, that was my understanding. Is that -- do you feel comfortable –
DR. FRIEDMAN: That's true, but it's also to have foundation standards that can be used for Part D going live and for the pilot.
MR. BLAIR: Right, yes.
DR. FRIEDMAN: And the critical takeaway on the foundation standards is that they don't need to be pilot tested because they're in such –
DR. HUFF: So the foundations don't need to be pilot tested --
DR. COHN: Yes.
DR. HUFF: -- and the time frame for going live?
DR. FRIEDMAN: Same date for both is January 1st of 2006.
MR. BLAIR: They don't need to be tested for them to be recognized and adopted, but in fact we probably will have to include them in the pilot tests because they're needed to test the other things that we're considering.
DR. COHN: Yes.
DR. HUFF: I remember all of the definitions of foundational but I just need refreshment. So when whatever standards are adopted by the Secretary, when are they mandated for use?
DR. COHN: Okay.
DR. FRIEDMAN: There's Karen. Karen? Just in time! Wake up! Welcome.
[Laughter.]
DR. COHN: And let me try to begin to answer this and Karen might be able to jump in if I'm misstating this.
One of the characteristics of the foundational standards was since they actually had widespread industry acceptance and were relative mature et cetera that they actually could be, if the Secretary saw fit, and obviously Mark McClellan and others I think had gone publicly trying to jump-start all of this, could actually be put into use in 2006, not as a pilot, but as, if you're going to do this, we think you ought to be doing it this way. And that was really the characteristic of a foundational standard.
Now, beyond a foundational standard are things that we thought were potentially promising but really needed to be piloted or tested, and remember, we had a whole set of things that we felt that were sort of the next phase, things that were improvements to foundation standards, terminologies, certain uses of identifiers, but other pieces that we really felt that needed to be tested in a pilot.
And that pilot would go on in the year 2006. The Secretary would create an evaluation which would be shared with Congress in mid-2007, would identify sort of the final standards, or at least the official full set of standards, in 2008, potentially for implementation one year thereafter.
And Karen, if I have misstated this all --
MS. TRUDEL: Through notice and comment rule-making.
DR. COHN: Through notice and comment – thank you – through notice and comment and rule-making. Thank you.
But the timetable, I think, is basically overall the right table because obviously a very deliberative process with all of the rest of it, and so does that help with your first question? Do you have other questions or do you want to make other comments?
DR. HUFF: Well, I guess there is one lingering question. I mean, in all that you said, I mean, for one of the foundational standards that we've approved –
DR. COHN: If we recommend it, if we recommend a foundation.
DR. HUFF: -- if we recommend it and that was adopted by the Secretary or through rule-making or whatever, by whatever process that happened, when would IC be found non-compliant if it wasn't adhering to that standard?
DR. COHN: Without having seen in those proposed rule-making, I don't know.
MR. BLAIR: Could you restate your question? I didn't quite understand it.
DR. HUFF: I don't know – I'm wondering if in the legislation it says a date by which if I'm not using the standards that were adopted that I will be considered non-compliant.
MR. BLAIR: Possibly, April, 2008.
DR. COHN: Karen, do you have a response to that?
MS. TRUDEL: It basically depends on when the standards are published as final standards. You can't find anyone non-compliant or not following something that is not effective. So it would key off the effective date of the final standards themselves.
And what we are hoping with the foundation standards is to link the effective date of the standards with the beginning date of the Part D program, but that again is a matter for – you know, we're still in the beginnings of the regulation phase. Does that answer the question?
DR. COHN: Okay. But I think regardless of all of this, I mean, I think the key view of a foundational standard is that you would have to be pretty confident that this was a mature, industry-accepted standard.
DR. HUFF: Well, that's what I was getting – I mean, that's really what I'm trying to understand, is how much time do we have? I mean, if we've got 12 years, then I would say, gee, let's do lots of interesting experiments with PKI and –
[Laughter.]
DR. HUFF: Twelve is hyperbole. I don't think it would really take that long.
DR. COHN: Yes. But now, let me layer on another piece of all of this, that I think, as I said, during my introductions which were of course – let's see; it was 6 a.m. California time yesterday morning and 7 a.m. mountain time yesterday morning – one does observe that e-signature has a variety of potential uses and use cases in health care that are beyond e-prescribing.
And one of the things that we really have a charge as a subcommittee and full Committee is to make sure that what we do really connects in with the larger national health information infrastructure, national health information network. So we need to make sure that all of this does come together.
This is really what interoperability is all about, so that we don't wind up with certain approaches for e-prescribing that turned out to be completely different than for what we eventually do when we're doing other aspects of all of this stuff.
And so we do need to be aware of that and we do need to realize that we actually potentially could give other recommendations which aren't just MMA recommendations, but we could suggest to ONCHIT or the Office of the National Coordinator that they go off and do something. Or we could ask CMS in pilots to do things, going up for MMA, or some combination of all of it.
So I don't mean to confuse you, but what I am saying is that we have a couple of different tools that we can use, and I think the bigger question is figuring out where it is we think we need to go, both what it is we think at this point as well as what it is we need to find out more about, because I don't think that we necessarily believe this is our last hearing or investigation of this investigation but it's sort of that a question like, well, where are we now, what open questions do we have? If we decided to do another half-day or day on e-signature, who might we need to hear from? As well as do we have any initial sort of views on all of this?
DR. HUFF: So you've answered all my questions, so you can go back to your opening statements.
DR. COHN: Assuming that I can even remember them!
I guess what I was going to start by commenting on – let's see how I can say this one. I find the PKI and really digital signature, and obviously the PKI infrastructure is a very fascinating and potentially very valuable sort of in terms of technology or set of approaches in health care.
I'm not at all certain about how exactly it works in with Part D and e-prescribing and certainly I don't think there was anything I've heard, at least from any of our testifiers today, though I think I'd want to hear more from people who have actually tried to implement it, that would make me believe that it is something that obviously I would feel comfortable with, maybe saying, this could be implemented widespread in the industry in 2006.
So I guess I'm just sort of positing this out – once again: Not having heard from groups like the VA or DOD or others who have really maybe tried to put this into a health care environment, you know, interesting but didn't feel to me that we were ready to say 10 months from now that people should immediately start with widespread implementations, which would be really sort of my definition of a foundational standard.
On the other hand, and something for the subcommittee to think about, is whether or not there ought to be some pilots or whether this ought to be part of an evaluation as you move into the pilots for MMA to figure out what sort of applicability might there be and should this really be the way, because I think one sense is that it's obviously a stronger set of security protections. It certainly, if connected with some sort of reasonable biometric authentication identification, that does really create that sort of chain of trust through the system, or at least helps cement it.
But that's something that would really have to be proven to make sure that it actually really worked as intended as well as opposed to as suggested and didn't overwhelm the industry, didn't bring down e-prescribing systems or otherwise.
So, I mean, that was sort of where I guess I was going, but I'm curious about what others think. But once again, as I say, we would want to hear probably from people actually using it to make sure there isn't some fatal flaw there. Other comments about this? Stan?
DR. HUFF: Yes – well, I can start off by saying
I can tell you a few things that I added to my list of sort of stuff from today if that's okay.
DR. COHN: Please.
DR. HUFF: Okay. So I won't repeat the ones that I said yesterday, but we had one at the end of yesterday that was preemption of heterogeneous state laws by a national e-prescribing standard would be important in order to achieve national standardization. And you're welcome to disagree with that.
DR. COHN: Okay. I don't think we said that; I think you noted that.
MR. BLAIR: I think what he's saying is that some testifiers said that.
DR. COHN: Oh, okay.
DR. HUFF: Well, I'm sort of asserting that I thought that was a consensus of what we heard, not that there wasn't some dissenting voice or something else, so –
The second one. So yesterday I said that we want to use the same e-sig process for scheduled and non-scheduled drugs, but then I think from testimony today, I added the statement: However, if the DEA decides to require digital signatures, then most folks thought that they would still want to use something, basically e-signatures, for the non-scheduled drugs.
MR. BLAIR: Could you clarify that one? You lost me on that. Would you restate it?
DR. HUFF: However, if the DEA requires digital signatures –
MR. BLAIR: For maybe the 15 percent –
DR. HUFF: -- for –
MR. BLAIR: -- yes, whatever.
DR. HUFF: -- scheduled drugs, and who knows whether it's just Schedule II or Schedule whatever, but then people would still want the ability to just go ahead with e-signature for non-scheduled drugs.
MR. BLAIR: When you say "with e-signature," are you saying –
DR. HUFF: Current best practices, basically.
MR. BLAIR: Oh, okay. In other words, have two different standards, one for DEA controlled substances and another for non-controlled substances?
DR. HUFF: Yes.
DR. FRIEDMAN: I got the sense that people weren't happy about that.
MR. BLAIR: You know, actually I don't know that I really heard a consensus. I kind of thought that that was one option, and maybe after we hear from DEA, we'll see if that's valid, if folks continue to say that or not.
DR. FRIEDMAN: The other thing that I heard was that if DEA proposes the digital signature that people essentially are going to drop back to paper.
MR. BLAIR: Yes. That was another.
DR. HUFF: Well, what I heard is they would drop back to paper for scheduled drugs --
DR. FRIEDMAN: For scheduled, yes.
DR. HUFF: -- not for all drugs.
DR. FRIEDMAN: No, because the DEA will only be for the scheduled drugs anyway.
DR. HUFF: So we'll have to sort that out, okay?
Another thing that I heard and thought made sense was standards should not allow the content or the intent of the prescription to be changed and we must especially preserve the transmission of sigs that are entered as free test without change.
MR. REYNOLDS: Say that again, Stan?
DR. HUFF: The standards should not allow the content or the intent of the prescription to be changed as opposed – we've said explicitly before that we were allowing the format to change.
MR. REYNOLDS: Can be translated, but not changed.
DR. HUFF: Translated, but not changed. That's probably better wording.
MR. REYNOLDS: Why don't we add that?
DR. HUFF: Okay. Can be translated, but not changed.
And the second part of the sentence was: "And we must especially preserve transmission of sigs that are entered as free text."
In other words, if some comment was made – and I happen to agree – that if somebody types a free text sig, then it would be inappropriate to change that into coded stuff that would have lossy transform and then try and change it back into something that the person at the pharmacy had to –
So, I mean, it doesn't preclude you from making a coded representation, but you still have to – I think the implication was, and I agree, that you need to send the text as it was entered by the physician in all cases.
MR. REYNOLDS: Would we want to expand that to be "any free text field would not be translated into a code?"
DR. COHN: Stan, I guess we would ask: Didn't we already make a recommendation on this? Am I confused?
DR. HUFF: You're right. This was probably one of those that's true but irrelevant.
DR. COHN: No, no!
[Laughter.]
DR. COHN: But one of the reasons why you thought it was true is you had already recommended it.
DR. HUFF: That's right. No wonder it sounded so good!
[Laughter.]
DR. COHN: I mean, no, no, don't delete it, but let's hold it and let's verify in our previous letter that we actually did say that. I'm pretty certain that I thought in our sig comments that we at least had made that recommendation.
DR. HUFF: So I think it probably is one of those things that's true but doesn't have any impact on what we're talking about here, so I think, good point.
So another one was, before I said allow for evolution that the recommendations should allow for approved experiments in new technology and new versions of standards or new standards. And then I added this sentence: "In particular, our recommendations should not preclude use and experiments with demonstrations of digital signatures."
DR. COHN: Say it again.
DR. HUFF: We want to allow for the evolution of standards. That is, that the recommendation would allow for approved experiments in new technology and new versions of the standards or new standards. And in particular, our recommendation should not preclude use and experiments and demonstrations of the use of digital signatures.
MR. REYNOLDS: That's our theory of a base set of standards, and then if people can go up from there as either experiments or pilots, and then if those are adopted, then the ceiling moves. I think we talked about that at our last –
DR. COHN: Yes. Let me just ask: Would those base set of standards be foundational standards or —
DR. HUFF: No.
DR. COHN: What?
DR. HUFF: I didn't say or hear anything about foundational standards.
DR. COHN: Well, I was just going to ask. I mean, when you said "base of standards," I just wasn't sure whether you meant these were all – I mean, we talked earlier about best practices and all of that; I just wasn't sure whether –
DR. HUFF: Harry said base standards. My thing didn't say anything about base standards –
DR. COHN: Oh, okay.
DR. HUFF: -- or base or foundation or any of that.
DR. COHN: Okay, fine. Thank you. I withdraw the question. You ask Harry that question.
Carol, did you want to make a comment? Please.
MS. BICKFORD: I have a question, and I have been listening to the discussion today, and it's us taking technology and replicating an existing system. And I wanted to know how we're going to be addressing the clinical decision support that needs to occur at the time the clinician is making the decision to prescribe and giving that individual the correct sig or the correct dosing or so on and moving it across the system. And does that occur before they file – in which case that becomes a constrained prescription and there is no change for it.
And we've only been looking at one direction in that the clinician sends the prescription off and it goes to pharmacy land, but the pharmacy may have a clinical decision support system that identifies that this is the inappropriate prescription for this patient. There might be drug allergies or wrong dose, wrong format, something. Then what happens to that prescription and the changes that occur in the pharmacy component? But then does it go back? Does that become encrypted then and PKIed and all those sorts of things? And what becomes the prescription then?
I'm throwing a bunch of things together that have been troublesome as I've been listening to this wrap-up. We've not talked necessarily about the re-work that occurs if something's wrong going through the system. But we've also not talked about the clinical decision support as being part of the e-prescribing solution.
Okay – well, okay; if you haven't gotten to that, fine. I just wanted to throw those two cents in. Thank you.
DR. COHN: Stan, did you want to try to comment on that or –
DR. HUFF: Well, I can say what we do in our own system. I mean, I think good informatics would say that you don't override the prescription you had with the changes that were made in the pharmacy, that you keep a separate record of that so that you know what came from the physician and you know what the pharmacy filled. And those are two separate and distinct records.
And if you have an interchange that goes back to the clinician and the clinician updates it, then that is an update. But even in that case, you don't override in some destructive way the previous prescription. You then have a copy of the original prescription, the updated prescription, and the prescription as filled, which are all separate and distinct information entities with their own audit trails and own audit ability.
MS. BICKFORD: But that's not been articulated in any of the discussion and it is obvious to us, so I just made the question.
DR. COHN: Alan, did you want to comment on this one?
DR. ZUCKERMAN: Yes, because this is extremely well articulated and documented in the NCPDP SCRIPT standard 4.2 which has a very clear set of two-way transaction.
Now, admittedly in today's world we don't see a lot of physicians having two-way communication with pharmacies; it's primarily one-way delivery of prescription. But locally I know several physicians engaged in this, and there is an initial new prescription transaction that goes to the pharmacy.
There's a transaction back to the physician completely separate that has pharmacist advice on recommended changes and new medications, new dose adjustment from the pharmacist, identifying both the person pharmacist and the pharmacy that this is coming from, and cross-referencing the prescription.
The physician then has a response transaction NCPDP SCRIPT that identifies his acceptance or rejection of the changes and creates in effect a new prescription which gets a new prescription number that cross-references the original prescription.
So if people use the NCPDP SCRIPT in its full two-way interaction, all of this is clearly documented.
What is a little bit different, though, is there are different clinical decision support systems to consider. Here we're talking about the pharmacist making advice back to the physician on changing a prescription and there's a way to do it. At the same time, there are clinical decision support systems embedded within the e-prescribing systems like DrFirst and others, and then there are clinical decision support systems embedded in EHRs such as NextGen which then has an interface to the DrFirst e-prescribing. So there are actually three different clinical decision support touch points within e-prescribing.
But the basic thing that you're talking about of a pharmacist recommending a change in dose or medication is very well handled, very well documented, within the NCPDP SCRIPT 4.2.
DR. COHN: Yes. Margaret, did you have a final comment on this one or is that well said?
MS. AMATAYAKUL: No, I was just going to say that one of the standards within SCRIPT is a change required.
DR. COHN: Okay. Stan, did you have other –
DR. HUFF: Two more quick ones.
DR. COHN: Okay, and then I want to go back to your first one for a second.
DR. HUFF: These are just assertions again, just like all the rest of them, and could be true or false.
Current e-prescribing best practices, if implemented as a national standard, would be more efficient, safe and cost-effective than current paper-based processes.
MR. BLAIR: I think that is a valid statement of the request that we heard from testifiers. I don't know if we can declare best practices to be a standard, and I noticed that when we tried to get them clarified, they were very ambiguous.
But I think it's proper to note that that was advice from the testifiers that we do that.
DR. HUFF: The last one was standards adopted should permit facts of e-prescriptions. That's all I had.
MR. BLAIR: Could I add one?
DR. COHN: Sure. Jeff, added one?
MR. BLAIR: And actually the one that I'd like to add didn't come from the testifiers; it came from our Chair. And our Chair pointed out – well, actually there were some others that also made comment about this as well – that when we look at the pilot tests in particular, and correct me if I'm misstating, that we should keep in mind that, whatever electronic signatures recommendations we go forward with, we keep in mind that they should be consistent with potential e-signature requirements for electronic health records as well, to the degree that we could do that.
And that seemed to me to be kind of a statement of our scope as we look at e-signatures. You broadened the scope. And did I state your assertion correctly?
DR. COHN: I think you did state that assertion correctly.
DR. HUFF: I mean, we had something close to that yesterday, and that was you said for e-prescribing to be consistent with e-sig and the rest of the medical transaction and data interchange, especiallly with HIPAA transactions. And we could just say "and other functions in the HER" or something like that.
DR. COHN: Sure.
MR. BLAIR: Well, actually, the HIPAA piece – I'm not sure, in the sense that HIPAA was the transactions between payers and providers, you know, on claims –
DR. HUFF: My example was claims attachments.
MR. BLAIR: Claims attachments, but I guess my thoughts –
DR. HUFF: In other words, I mean, all I'm really saying here is not all HIPAA. Maybe I should restrict it and just say that if e-signature for –
MR. BLAIR: The potential use for electronic health records. I thought that's what you were saying.
DR. COHN: Yes, and I think that Stan is obviously talking about, given that most of the HIPAA standards don't require signature, I think Stan was obviously coming up with the specific piece. And I think that's probably consistent with what you're describing.
So hopefully both of you – hopefully the wordsmiths get together a bit. Steve, you had a comment?
DR. STEINDEL: I have a question. Is this is a goal –
DR. HUFF: Yes.
DR. STEINDEL: -- or a requirement? Because we don't know what --
DR. HUFF: We have all these goals, assumptions and guidelines in what we might recommend.
DR. STEINDEL: -- the signature requirements are going to be for the electronic health record.
DR. HUFF: I'm just saying in an appropriate world, if we did know, we would want them to be consistent.
DR. STEINDEL: As a goal statement, I can agree with that.
DR. FRIEDMAN: I think I made that statement yesterday that some of these, or at least for e-sig, that were out in front of the standards for electronic medical record and a lot of other things like that, so it's hard in my mind to conceptually think about how to reconcile consistency with something that hasn't been invented yet.
MR. BLAIR: But could I just clarify one little piece?
The reason that I reacted, Stan, on the HIPAA piece is that we had been told that a lot of those financial claims transactions didn't require electronic signature, so that was why I didn't feel like that was something that was playing in as much.
DR. COHN: Stan, I'd actually like to just go back to, I think, your very first bullet, which had to do with federal preemption. And I would certainly say that we heard a lot about that though I'm just not sure I've heard quite enough about it to put my arms around it in any way that is beyond a high level piece.
I guess as I was listening to things, and I'm just sort of curious about what others think, I think I came away feeling that there really does need to be as much as possible increased consistency between state and federal practices and rules and all of this in this area. And certainly you don't want a situation where Part D prescriptions are somehow handled differently or governed by different rules than non-Part D prescriptions, which is, I think, where we're all trying to drive to.
The point that I would, however, make is that that's an outcome that we seek, and federal preemption is one tool to get to that outcome, and we're probably, if we're talking about all this, at least need to be aware that there are probably other approaches that can get to the same ends.
And once again, I'd almost need to hear more, but, I mean, one sense is when one was talking about the e-sign and UETA stuff and all that, you sort of saw an example of where there were federal things but there were state things and by everybody working together, yes, there are some variations there. But it seems to sort of work by everybody collaborating together.
So I'd only say that there are probably some different models that we may want to at least provide for, or at least to further investigate.
DR. HUFF: I would agree with the further investigate, but I tend to adhere to Clem's adage, which is you'll end up with the number of standards as you have standards bodies.
[Laughter.]
DR. HUFF: Well, human dynamics being what they are, if independence is allowed, it'll be exercised.
DR. COHN: Well, Stan, I was actually noting with Kepa here yesterday that we were missing somebody, and maybe we needed to ask Dr. MacDonald here for some of his wisdom and guidance on all of this.
DR. STEINDEL: Well, I'd like to make a comment in that area. I mean, it is the observation that the number of standards is related to the number of standards bodies.
But I would also like to make the observation that the amount of time it would take to get the same standard using federal preemption may be longer than if we found another way to do it by consensus process, because we already don't have a very clear articulation of what the federal preemption in MMA means.
And we also have enough instances where federal preemption has been enunciated in multiple laws where it takes a while before it actually diffuses out and becomes the national standard, and if we want a national standard for e-prescribing in the few year time period, you know, that that may not be the way to get it.
DR. COHN: I keep looking to you to make a comment.
MR. REYNOLDS: Yes, I'm going to. Let me speak on that one first.
MMA is a federal program, We're talking about – right now, our only charge is to put together standards for that federal program, even though we're trying to keep mindful of everything else that's going to happen.
And no matter what we put together, it's going to trip over every one of these state situations, and you can pilot forever. So you're talking about, you're putting in a benefit as you think of health care. You're putting in a national benefit and trying to run it through a state filter.
And so as we put this together, I like the way Stan said it because I think we do have to be focused, that the only way it's going to be successful and not trip, and the only way you're going to get general adoption – as we've heard from the testifiers – and the only way a standard's going to a standard a little bit like HIPAA was, where an 837 is an 837 is an 837 and the states really don't have a whole lot of say in it, I think the umbrella is there. I think the philosophy is there, and I think in this case – I liked a couple of the words that were said today, mobility of people.
You know, you've got so many – there's a lot of consultants in this room, that they may call their doctor at home today and get it filled down the street here.
Depending upon how that's going to work, they may or may not get it filled down here, based on this state versus the state they live in versus everything else.
And back to your earlier point. We may want to not only just hear more; we may want to have – I know I'd love to see the DEA in here at some point because you have a couple things, philosophically now, not in any derogatory –
We have a speed bump called the state differences. We have a speed bump called what is the DEA going to do – not good or bad, just what is it going to do? Because that's another one.
And so if we're trying to set a standard that's going to move and be adopted, I mean, those are two bumps that are going to need to be looked at and either smoothed out or accepted that they're there and then build whatever our standards recommendation is around them because otherwise, I mean, they're not going to go away. And they're going to be clear and they're going to be precise.
So I think in going forward, we're going to have to deal with it. I struggle right now making a recommendation because I think we've heard probably DEA said 150 times today and yesterday – not negative or positive; it's a fact.
And so we're about to recommend something which could be trumped by something else, and that's a little disconcerting just because there's not even a framework up there now. I mean, I don't care what they put on the board, but at least it would give us a framework just to find out if we've got any chance of even – so that's my comment. Later on, I want to comment on just some other stuff. And I'll leave this one on the table.
MR. BLAIR: I would hope we don't make recommendations before we've heard from the DEA.
DR. COHN: Well, it sounds like we've identified something we need to try to do in January. And I think just for the record, at least my understanding is that the DEA is going to do something as a proposed rule; it isn't a final rule. So just be aware their process is the same as HHS's process in terms of that. So what comes out as provisional versus what finally gets decided sometimes does change.
DR. FRIEDMAN: Speaking for us, if our rule is out by the time of the next hearing, we will brief you on what our rules are.
DR. COHN: Sounds good. Now, other comments about this particular – we've heard that we've probably got to get the DEA there and obviously, you know, you've made a couple of comments about federal preemption as it applies to all of this.
Now, you had some other things that you wanted to talk about.
MR. REYNOLDS: Yes, I do, yes, I wanted to mention a couple of others.
As I think of Stan's list, this whole federal assurance level thing that came out yesterday – you know, the one that was presented that went through all the different levels, and as you try to build something, because as I sit and look at this, and whatever we would recommend is going to go through some filter and this could easily be a filter.
And you think about like it has a Level 2 here where that was a PIN and a password. And I think Lynne said it in her discussion today; you know, you have a registration, password and a PIN, in a secure network. Now, you start layering those together, you move off of 2 closer to 3 and 3, if you remember, is high confidence in asserted identity.
I'd have a hard time not at least considering and recommending some standards that at least put you close to the 3, because the 2, the words in the 2, kind of make you uneasy, and that's some confidence! [Laughs.] Some confidence in the identity.
And I think that what we've heard with the process that is currently in place with everyone is the whole idea that somebody's got to be registered with one of these networks and you've got to put in the PIN and a password and it's going through a secure network. Those layered together, and again, as I mentioned to Simon, I just went through some of the Sarbanes-Oxley stuff and the more you can layer on, the better your thing is.
So as we look at how we view this, there's a difference between just picking PKI or just picking something else and making sure that we've put together a package of a recommendation of a layered structure. I
don't know exactly how to term that so that's why I'm struggling with the words, because this thing, this is a very valuable tool. I mean, this is an interesting tool to use. And it's obviously a tool that's not going to go away and it's obviously a tool that's been well thought out and it's a tool that's going to keep showing up.
And I would have a hard time not seeing us push closer to 3, as close to 3 as we could, at least philosophically, as we think about what we recommend, because you can pick one piece or this piece. I mean, I think that whole thing, because that high confidence – the whole thing about the electronic signature is it's a high degree of assurance, a reasonable degree of assurance that that person did it and that everybody in the game takes that seriously.
And then one other thing I'd like to add is I feel that with HIPAA security and privacy – and I actually will withdraw my earlier discussion yesterday – where I don't necessarily feel that the vendors, based on the further testimony, and one of the reasons I threw it out there was to try to learn a little more, I don't feel that with what I've heard on the way this goes from the physician system and then it gets into the other process and goes to the pharmacy and what the pharmacy does and everything, I don't feel an overriding necessity now to include vendors, which would take a change, a significant change, in the reg as it is now, and I think would impede progress. And going to have it wouldn't necessarily do that much for it.
DR. FRIEDMAN: To clarify your saying about broadening the scope of covered entities –
MR. REYNOLDS: Yes, but I think anybody under e-prescribing that is translating should be considered part of a clearinghouse which – that's a clear definition already that's out there in the industry.
MR. BLAIR: Harry, could I get a clarification? When I think of vendors, I think of the health care IT software developers that develop the e-prescribing systems, the DrFirst, the Allscripts.
MR. REYNOLDS: No, I'm thinking more of the practice management systems.
MR. BLAIR: Oh, you're thinking of the practice management systems.
MR. REYNOLDS: Anybody – once it leaves the doctor's office and goes into someone, in my opinion, they are in e-prescribing.
MR. BLAIR: Okay. Now, then help me a little bit further because I had thought when you made your comment originally about a clearinghouse that you were thinking of the networks, the ProxyMed and the SureScripts.
MR. REYNOLDS: I was, but if you remember, Jeff, they stated in testimony that they were not part of the HIPAA regulation. But yet if we authorize people to translate the information, then by definition they are a clearinghouse and that's my point.
MR. BLAIR: Okay. Then I think that we agree.
DR. HUFF: Isn't that only true if it's a HIPAA transaction?
MR. REYNOLDS: That's a good question.
MR. BLAIR: And my thinking on this is that I don't think it's necessary – well, how do I want to point this out?
Functionally, if they're opening up and they're looking at PHI, protected health information, which the prescription probably would be, then from a functional standpoint I would think that that's analogous functionally to a clearinghouse function.
As to whether or not a regulatory or legal action is taken to declare that SureScripts and ProxyMed become clearinghouses when they do that, I really – to be honest with you – I don't really care whether they're – that's a regulatory issue and a legal issue.
I do think from the standpoint of our subcommittee, we have to recognize the reality of that function and that it is opening protected health information. So I think we have to treat it from a standards standpoint. And I won't use the word "clearinghouse." I'll just wind up saying we have to recognize that their level of security and privacy has to be consistent with what they're looking at.
MR. BROOK: Legally – and you brought up the term before – we have an obligation with PHI regarding security and privacy. So you did bring that comment up, and that's a fact, and all of our contracts clearly state that regarding PHI.
MR. BLAIR: I think that's all that's necessary at this stage, unless there's some other rulings that HHS feels they need to do.
DR. COHN: Maria?
DR. FRIEDMAN: As I heard the discussion yesterday, it seemed that the people who are involved in the chain, switches and all those other people, while they consider themselves covered entities, they felt like they had met the HIPAA security and privacy threshold and in addition to which were covered under their business or their trading partner agreements that were mentioned, their contracts.
MR. REYNOLDS: The only reason I continued to make the point is they are not translating information, and that is a clear stipulation. When you start manipulating data, you're going into a new game than just passing it through. I mean, you're into a whole new world of responsibility.
That's why I'm struggling as we go forward. We've got a HIPAA umbrella, but what are we doing?
DR. COHN: Yes, and I think we need to do a little more research on that, but Karen, maybe you have either some clarity or I mean at least we can hold that out as an issue that we need to, I think, go back and look at the security rule and other things about. Karen?
MS. TRUDEL: I believe that the regulations stipulate that a clearinghouse is an organization that translates transactions for which the Secretary has adopted standards into and/or out of standard transaction formats.
So what that means is that if someone is just translating prescriptions, it doesn't make them a HIPAA covered entity. If they are translating – and many of them do, and I think I'm seeing maybe some nods back there – retail pharmacy claims, 270/271, et cetera, they're a covered entity already because they're doing those other HIPAA transactions.
MR. REYNOLDS: You're saying that the law says that anything the Secretary sets standards on, then they would under HIPAA privacy and security? Is that what you're saying? Or a covered entity under that?
MS. TRUDEL: But if you look back at the HIPAA law, it specifies that 10 or so transactions, including claims attachments for which the Secretary is expected to adopt standards, and then it says and any other administrative transactions, or some language in that vein.
So it leaves the door open for the Secretary to adopt standards for additional transactions at some point in the future. But remember, when you do that under HIPAA, you're doing it for the entire health care industry and it's required and there are implementation dates and it's very different than doing something just for Part D of Medicare.
MR. REYNOLDS: Well, and that's what I'm saying. I mean, our only authority right now to recommend is on MMA, right, basically?
So I just want to make sure. Again, if they hadn't testified that they weren't involved in this, I wouldn't have been maybe as adamant.
DR. COHN: Okay. Well, I have a sense that we're sort of dealing with an issue of fact here and I think that we probably can just go back and take a look back through the legislation, the regulation. I think we know how privacy plays, which is different than how the best of the HIPAA regs play in terms of their interpretation of things.
And I think I was observing that I was a little less certain exactly the wording around the security rule, so I think it's something where we can go back just as a matter of fact and review it and then come up with a recommendation that sort of reflects that bit of information.
So I think we hold this out as something that we'll probably want to comment on, but exactly how we comment on it requires a little more research. Is that okay?
MR. REYNOLDS: I'm good with that, yes.
DR. COHN: Okay. And other people have comments about what they either heard or what they believe or what they would like to see at this point? Do we want to talk a little more about the sort of unanswered questions that we may want to – or things that we may want to hear in January? Margaret?
MS. AMATAYAKUL: I had noted two things that didn't seem to be included in Stan's list. And one of them really kind of surprised me a little bit, was the issue of record retention. And in association with electronic signatures, I know a number of the state laws address signature in relationship to retention.
And so it might be prudent to look at the record retention issues that were brought up by several of the testifiers in relationship to how that is handled with respect to e-signature. This is something to keep on a laundry list for.
And the other thing that was mentioned that I'm not sure is on Stan's list, maybe it is, was a certification process for vendors. We do have a certification commission that has been started under the ONCHIT to look at EHRs for physician practices. And the thought was that they would then move down the chain to have other types of products. It may be appropriate to look at e-prescribing products as the next task.
DR. COHN: Okay. And I only would disagree with you – since that was one of our earlier recommendations which you helped us craft, which is why I think you remember it so well. I guess we need to see if we needed to redouble in whatever letter, so –
MR. REYNOLDS: I think back to the federal structure again; that's the other kind of thing that moves you from the 2 to 3, your certified systems, and you need to do these other things also to start moving it up.
DR. COHN: Well, Harry, I'm getting the sense that we probably as bedtime reading over the next month need to review the 2 to 3 definitions. I think we actually all have the NIST documents, and we want to thank Judy for giving that to us, and it's actually in 12-point type so it means I can read it without a magnifying glass, so that's always a good sign. But I think that that'll be something we can, I think, talk about.
DR. STEINDEL: I have a comment about certification.
DR. WARREN: No, mine is just trying to understand something. You can go first.
DR. STEINDEL: I just wanted to point out, and maybe I should either make a non-disclosure statement or something since I chaired the group, that the HL7 EHR TC has posted and is reviewing a set of conformance criteria for e-prescribing I can share with the group, if you wish. So that's a start of forming certification.
DR. COHN: Okay.
DR. STEINDEL: But this is not an HL7-approved document in the sense that it's being developed, and it probably will not go to ballot for a while but go out for public comment in the near future.
DR. FRIEDMAN: It'll be interesting to see where you are, though.
DR. COHN: Judy?
DR. WARREN: Well, I'm still trying to connect the dots on all this. I think that I've heard – and if I'm wrong, I need to know now before going further and connecting the dots – is the statement that e-prescribing is outside of HIPAA, is that something we're saying?
DR. COHN: Yes, it is actually not one of the HIPAA transactions.
DR. WARREN: Then the problem I'm having is under HIPAA we have this whole thing about the private information about that patient. It would seem to me that what drugs that patient is taking is – okay, Steve's over there nodding his head "wrong." Somewhere I'm not making the right connections here on what we're doing. I don't understand why knowledge about what drugs the patient has been prescribed is not protected information.
MR. BLAIR: It is.
DR. COHN: It is.
MR. BLAIR: It is. The thing is, HIPAA was passed in '97. pr '96, and MMA was passed in 2004, so when HIPAA was passed, it focused on the transactions between payers and providers, all of the financial administrative transactions that were built in the enrollment, all of those things, and the only reference it had to clinical information was that it asked NCVHS to wind up setting four standards for patient medical record information. That was what it referred to it as – patient medical record information.
And we sort of went down that path, but it wasn't as mandates, and those turned into the CHI standards, and e-prescribing wasn't on the legal or regulatory radar screen until the MMA law was passed. So now you could now look back and try to integrate those, and in that case you'd look at protected health information that's in e-prescribing and say, hmm, that does fall under the privacy and security portions of HIPAA.
DR. WARREN: Okay, so it's a technical –
DR. COHN: Yes, and I think we have lawyers that can help us on this one, maybe to further clarify and – should I try, or Karen, do you want to try?
MS. TRUDEL: I'm not a lawyer, but I'll try it anyway.
The actual importance of being or not being on that list of transactions in HIPAA is twofold. One is that we haven't at this point adopted any standards other than the ones that were originally on the list so we can't require the industry as a whole to right now implement, for instance, the NCPDP SCRIPT, without going back and doing another HIPAA regulation. So that's one part of it, that there simply isn't a legal base right now for us to adopt and enforce rules about that without going through notice and comment rule-making, which we're not doing.
The other thing is that whether you're on that list or transactions or not is part of the threshold issue of whether or not you're a covered entity. For instance, a provider is not a covered entity under HIPAA unless it
conducts one of those transactions electronically, and since the electronic prescription is not one of those transactions, if that is all a provider did electronically, that wouldn't push them over the threshold where security and privacy then become engaged. Does that make sense?
DR. WARREN: Yes.
MR. REYNOLDS: Does the same thing fall for a clearinghouse?
DR. WARREN: Karen, can I get a clarification?
[Laughter.]
DR. STEINDEL: I have a clarification. You said security and privacy. Is it both, or does privacy still apply because privacy applies for electronic and non-electronic whereas security I would agree with does not apply?
MS. TRUDEL: The threshold is still there, Steve.
If you get over the threshold and you become a covered entity, then privacy applies for both electronic and non-electronic.
DR. STEINDEL: So if they stay out of the HIPAA transactions –
MS. TRUDEL: If you don't go over the threshold.
DR. STEINDEL: -- they don't have to worry about privacy.
MS. TRUDEL: It's moot.
MR. REYNOLDS: So if you only are only the business of prescriptions and only in the business of e-prescribing, you would not fall in there.
MR. BLAIR: We're not going to be able to keep that separate because we're looking at getting medication history and medical history and information, all of the information for decision support. So we're not going to be able to keep it separate.
MR. REYNOLDS: That's my point, Jeff. The whole point I'm talking about is we've got an umbrella and how do we –
MS. TRUDEL: The HIPAA threshold still stands.
MR. REYNOLDS: Yes, and so how do we make this work, so I don't know. It's interesting.
DR. COHN: I think I'm once again reminded that we may actually have a little homework.
DR. WARREN: I just don't think I understand.
DR. COHN: Well, no, no, I think that we're talking about fine differentiations here and I think what Karen said is absolutely true, what Jeff said is actually absolutely true also. One could imagine use cases or business models where maybe not everything that was recommended by NCVHS is implemented.
So maybe all of the HIPAA transactions that we've been talking about or recommending maybe aren't be used and only NCPDP SCRIPT, and in those circumstances, without the 270/271, without the 275, and if they're not dealing with other parts of the transaction from the pharmacy to the PBM, there really might be some examples there. Now, they may be rare, but it probably is worthy of some sort of an observation about all of this. Yes, Karen?
MS. TRUDEL: If I could just add one thing. I think this issue is relatively immaterial when it comes to pharmacies because so many of them already do the electronic NCPDP retail pharmacy drug claim. The penetration of that transaction is so high that I would think there aren't too many pharmacies that would do e-prescribing but not do electronic claims. That just doesn't seem to compute.
But I think the issue is more on the prescriber side.
DR. STEINDEL: Karen, do you have any idea of what percentage of prescribers would not be doing electronic claims? That would seem like it would be very low.
MS. TRUDEL: I think it would be very low because I think you're going to find that anyone who is thinking about getting into the electronic arena is going to do it first through administrative transactions which are relatively straightforward when compared to e-prescribing,
HER et cetera. So I see it as a progression.
I'm not sure this is a huge issue in reality. It's an interesting legal discussion, but I'm not sure that practically speaking it's a problem.
DR. STEINDEL: Yes, and then my other point of view is even if there are some, I would imagine the volume of transactions is so low that –
DR. COHN: Yes. I guess I wasn't necessarily singling out any particular entity; I just thought we needed to make sure that the beginning to the end is appropriately covered. And I think, Harry, you at one point had brought up issues about the value added networks and all of that. That all may be covered. I'm just sort of priming myself sort of like I think we need to go through a map and make sure that all the groups are appropriately covered with the right umbrella of security and privacy, and if not, we need to comment about it.
Or if there needs to be potentially some clarification from HHS around all of that or some comment in future rule-making or other, that to me is – I don't know whether there's a problem here, like Jeff; I'm not sure that there is, but just that we need to do our homework and make sure that this is all connected. Harry, does that –
MR. REYNOLDS: That's exactly – I just want to make sure that we're clear either in not making a recommendation or in making a recommendation for clarity if it isn't clear exactly how people fit and don't fit and what is the umbrella over them, because on the one hand you might be in the case of a blue, we might be getting the transaction from a PBM and protecting it under HIPAA.
And that's also electronic health record data and that's also claim data – I mean, it's also everything else. You want to make sure that the rest of the food chain also has taken equal care because our responsibility is to our member, the doctor's responsibility is to the patient, and you've got to make sure that when it gets outside that little loop that the world's covered. That's all we're doing. So I just want to make sure that we know that that loop is covered, and then whatever recommendation comes out of that, or doesn't come out of that, is just – well –
DR. COHN: Margaret is keeping these things as "to-do's" for the Committee, so we've got reading the NIST Level 2 and 3 document for January and we needed a little bit of mapping for the process flow and to make sure everybody's we think appropriately covered.
Now, let me just ask – I'm just going to sort of move the conversation because I think we have things; we can look at them, we can think about them.
Now, we will talk tomorrow something about the January hearings also, but since we're really talking about the whole issue of e-prescribing and e-signature and all that, I mean, I've heard so far that we need to see if we can get the DEA and probably the Department of Justice sort of involved. I mean, and really the Department of Justice – and maybe DEA and Department of Justice are the same in this one; well, it may be all handled – but I just sort of thought that the issues about business cases and use cases and their perspectives about this issue of non-repudiation and all of this are I think an important thing for us to at least understand.
MR. BLAIR: I suggest we give Maria subpoena authority so she requires –
[Laughter.]
DR. FRIEDMAN: I just want a badge!
[Laughter.]
DR. COHN: So I think we'd like to get them if we can, and if we can't, we will sort of just so note in our letter.
DR. FRIEDMAN: I think it's going to be a timing issue.
DR. COHN: Well, if not then –
DR. FRIEDMAN: We actually hoped to have them this time and the timing was not right.
DR. HUFF: A question related to that, Simon.
DR. COHN: Sure, okay, we can move on.
DR. HUFF: I mean, is it our feeling that before we could make a recommendation relative to e-signatures or digital signatures that we have to have the input from the DEA? The corollary question is: Is there anything we think we could recommend without knowing what they're gong to do or is it entirely dependent upon what they're going to do?
DR. COHN: No, I think that what I was trying to say is that it would be very nice to hear their perspectives on all of this, and even without hearing whatever they may be thinking about in terms of a rule, I'm actually thinking more about what it is that they need to do and the strength of things like non-repudiation and all of that that they believe that they need to have, which to me is – and those were a proposed rule. A final rule was the implementation of that. But it's really more the questions of what are their use cases, what are their business cases around this, just so we can understand better, because I think that's very useful.
Is it essential? I don't think it prevents us from making additional recommendations to HHS but I think whatever recommendations we might make, I think we would want to note whether or not we had heard from them or not just because I think it would be an important thing to put in the letter. Do you feel otherwise? I mean, do you feel that we need to hold everything up until we can hear from DEA?
DR. HUFF: It was my feeling not. But then, on the other hand, I think a lot of what – well, put it this way, so I'm just conjecturing. I mean, at this point in time, without further information, I would be thinking along the lines of figuring out some way of recommending best practices in certification and other things that seem, you know, testimony said would reasonably meet today's needs and would not be an impediment to implementation of these systems.
On the other hand, once something happens, it's hard to judge the effect of that on your impression because all of these guys who testified that way might say, oh, if this is going to be mandated by the DEA, we're going to have to do the software work in our systems anyway, and doggone it, we hate it, but we think we would want to just do it one way anyway. And that's what I worry about. I don't know the answer to that question.
DR. COHN: And I think we did ask them during testimony.
DR. HUFF: Yes, and I think conjecturing about how you might respond is different than actually responding when it happens.
DR. COHN: Well said. Jeff?
MR. BLAIR: The other piece that I think really has us in a very difficult situation is what you alluded to just a few minutes ago, is we don't really understand the risks and exposures that the DEA is trying to mitigate with its ruling. And for us to start to make recommendations without understanding that, I just feel like we're on shaky ground.
DR. COHN: So I guess what I'm hearing, we should invite the DEA to come and meet with us in January. Was that our conclusion here?
I had one other area. The other piece that I thought we needed to hear from and I was just observing as I was listening yesterday and today is that we need to hear more from physicians, physician users of all of this. And I'm thinking of – we heard from Alan Zuckerman, who was, I think, unique in the fact that he was a physician user, but we need to be hearing from other specialty societies as well as the AMA to get a better feel for sort of their perspectives on requirements, so that was the other piece I was going to say. I'll stop.
DR. STEINDEL: I thought we heard from the physicians early in the process. A lot of physicians.
DR. COHN: I don't think we heard about e-signature.
DR. STEINDEL: Oh, not e-sig – oh, you're talking e-signature.
DR. COHN: I'm talking about the e-signature.
DR. STEINDEL: I'm sorry.
DR. COHN: No, we heard lots from others. We just never heard it from them about PKI, all these other things. I'm sorry.
DR. STEINDEL: Maria, what's holding up DEA is the release of the regulation, which is why they won't – you know, if we're going to hold up our process waiting on the regulation where the Department of Justice has just changed Attorney General and HHS is just changing the Secretary, I don't know when we could get this letter done.
MS. TRUDEL: I think we can go back to them and ask if they could come in and talk at least at a fairly high level and especially about their business drivers and what's causing them to think that they need certain levels of authentication. We had hoped that we could just have them come in and do a presentation on the MPR and I think that having them come and do the one is very different than the other.
DR. STEINDEL: Thank you. So they were invited specifically to talk on the NPRN.
MS. TRUDEL: And I also asked them if they could talk about the MPR and could you do the other and the were reluctant to do that. But that was then and this is now and we can go back again. We'll do what we can to make that happen.
MR. REYNOLDS: We saw this picture a lot – your picture – and I think a couple of questions were asked; so, are there any standards – when you take your blocks 2, 3 and 4 – that are what they might want to have accepted?
I mean, obviously the data flown across here is an NCPDP SCRIPT. But are there any standards? And it might not hurt to just ask the industry one more time whether or not there are any standards.
When you talk about a secure POC network, when you talk about a secure network, when you talk about these other things, is there any already accepted standard that would be worthwhile? And then obviously you add the PKIs and you add the other stuff in there, but is there any other thing that would be a part of this that would be in place that we could adopt or recommend adopting? Other than just saying "a secured network."
DR. STEINDEL: There are a lot of standards that are being used. SSL is a standard.
MR. REYNOLDS: I understand that.
DR. STEINDEL: Yes, and they're not in the world that we deal with; they're in the IT world and the security world.
MR. REYNOLDS: I live in this world.
DR. STEINDEL: I don't know if we're really skilled enough to pronounce specific standards to use there. I mean, there are people in HHS. I can bring people from CDC who can give you the whole list of standards that are used in that area. There's people just down the hall who can do it here within this building. They exist in their standards; they're just not the ones that we're familiar with.
MR. REYNOLDS: I understand. My point is – you may have already answered the question. You've made a statement that we don't need to worry about that. If we don't need to worry about it, I'm good with that.
DR. STEINDEL: We handled it. I think we handled it – Karen, you can address this a little bit better. We handled in somewhat of a vague way in the security standard because we knew that there were industry standards in that area and we basically alluded to them, didn't we – best practices, document the systems –
MS. TRUDEL: Well, we talked a lot about scalability and flexibility. In terms of specific standards, no, we didn't do that in the security rule, deliberately so.
DR. STEINDEL: And deliberately so. And I think we need to remain at that level.
MR. REYNOLDS: And that's fine. Then you answered the question. All I was looking.
DR. HUFF: Well, I guess I would ask the more general question which maybe comes back to that same question – I mean, if our intent was in some way to "approve or suggest or adopt best practices," I think our only pathway to do that is by reference to particular standards that we would recommend that they adopt as "best practices." Otherwise, I think all we can say is a fairly generic statement about, you know, go forth and do good.
MR. REYNOLDS: If you look at the security reg, Simon, the security reg says do your assessment, put in place what you think will protect what you have, and then you got to kind of live with it.
DR. COHN: Let me make a comment on that in just a second, but, Stan, I would certainly deputize you to review the standards that Lori put on her overhead and come back to us.
I think an equally valuable piece might be this NIST document that one might want to reference also.
Lori, did you have a comment?
MS. REED-FOURQUET: Yes. There are some additional ASTM standards that don't necessarily talk about PKI that you might want to take a look at that address health care specific transport and the encryption and general frameworks. ASTM 2086, which is the standard guide for Internet and Intranet health care security and ASTM E2085, which is a standard guide for security framework for health care information. Those two build on the underlying IETF standards in the context of health care.
MR. BLAIR: Lori, are you able to make those available to the subcommittee?
MS. REED-FOURQUET: Yes.
DR. COHN: Okay. Thank you. I think we have a comment from Phil. Please introduce yourself. Thank you.
MR. ROTHERMICH: Phil Rothermich from ExpressScripts. I just wanted to underscore the point we made when we went through this diagram.
I mean, the bullet points that we included were really intended to be sort of a straw party for what the standards could be. So the first bullet under Practice is the point of care vendor authenticates a prescriber before assigning a unique IDM password.
So while that's sort of vague, in the context of a standard, authenticating in the prescriber could be a standard and you could list the things they have to do to authenticate the prescriber. In other words, check the state license, confirm that it is current; check the DEA number if that's important to you. Make a list of things, and the standard is the point of care vendor does all those things to assure that this is really an authorized physician to do prescribing, and then check the box and you've met that standard.
And, you know, you go down the list – authenticated prescribers are granted access to POC technology using unique user ID –
DR. HUFF: But if I understand it, our usual mode has been to adopt standards. I mean, that would imply that we're actually making a standard.
MR. ROTHERMICH: Right. This is an area where standards don't exist.
MR. REYNOLDS: That's designing a process.
MR. ROTHERMICH: Right.
DR. HUFF: Is that part of our subcommittee charge, to make standards? That seems a little outside of –
MR. ROTHERMICH: That's exactly the charge.
DR. HUFF: No, I would have thought it would happen the other way, that you would take that kind of recommendation to NCPDP or HL7 or somebody; they would create that as a standard, then we would approve that standard as meeting the needs.
MR. ROTHERMICH: My recollection is that somewhere in the statute or something it says that the charge is to leverage as many existing standards as are possible, but it seems to me there was a recognition that there isn't a standard for everything when it comes to using a secure network.
DR. HUFF: Well, but that was in reference to the government in general and I don't think the charge of this Committee anywhere says we should create standards. But maybe I'm wrong.
DR. COHN: Without answering that question, I'll let Margaret comment. Maybe she has a suggestion on this one.
MS. AMATAYAKUL: I think we should review the existing standards in ASTM because I think some of the language we're looking for really does exist there. Many of these are fairly new standards, within the last couple of years.
And then, if it seems like those standards don't suffice, then I think maybe a recommendation along the lines of passing a specific standards group or a group of standards groups to come together and develop those standards would be appropriate.
DR. HUFF: But I appreciate, Phil, your clarification of what you hoped would happen.
DR. COHN: I think once again I don't think we have enough data at this point to make a decision, but I do like Margaret's idea of reviewing the standards, which I think makes a lot of sense. I think, Phil, you guys produce a wonderful framework for all of this and I'm finding myself looking at this, thinking about the NIST document. Hopefully, Margaret will tell us about the ASTM documents that she's going to review for us.
And try to figure out how it all fits together and whether – yes, one would observe that the HIPAA security standard is basically the script of an evaluation standard. So I don't think that we necessarily at this point would tell you how it is we're going to approach this. I think we do need to do our homework.
MR. ROTHERMICH: Yes, let me just make one clarifying point. I mean, I guess my assumption is the charge of the Committee was to create standards for electronic prescribing.
PARTICIPANT: Recommend.
MR. ROTHERMICH: Recommend, okay, to recommend standards – even better.
In other contexts, before we got to this problem, we recommended that we take what ARTP(?) was doing with respect to a certain couple transactions and recommend those as the standard. And to get people comfortable, we said we'll take those through NCPDP to get them validated by the industry.
So in a way we would be doing the same thing here. We would recommend the way people are doing things today be recommended as the standard and maybe go to NCPDP or somebody and say, get the industry to agree this is the right way to do it.
I mean, to me, there's a very parallel analogy there.
DR. HUFF: I think it is parallel, but I think you need to go back and look what we did because what we did is said these are proposed or non-foundational standards because they weren't true standards and that we would reserve judgment based on the process in those committees about whether we would truly adopt them as standards or not.
So the point being that if for some reason that process breaks down, we have the discretion to say no, those are not the standards.
MR. ROTHERMICH: Right. I'm just suggesting you could use and sell the process for these to say if the point of care vendors are authenticating prescribers this way today, we think this a good way to do it. Get the industry to agree this is the right way and then call that the standard and say everybody's going to do it one say.
DR. HUFF: I mean, I think, again, the right process for that would be the way that you know that's an industry standard is that NCPDP, ASTM, HL7, DICOM, somebody, convenes an open consensus process to approve that, and then we feel comfortable that we could go ahead.
DR. COHN: Feeling badly for Lynne, who I notice is not commenting in the corner.
MR. BLAIR: I almost feel like there's a potential convergence here and I just know some bits and pieces, so I'm just trying to connect them.
Margaret pointed out that we ought to review the ASTM standards. I remember four to five years ago there was an ASTM standard guideline for health authentication and maybe if we all get a chance to review that, that's an ANSI-accredited standard for authentication of health care information or health care – I'm not exactly sure what the words are, but I guess it's authentication of a person who's entering health care information.
And if that turns out to mirror very nicely with Phil, the industry guidelines that you have suggested, then in a sense we not only have adopted the industry guidelines but we've done with a standard that's already ANSI accredited and we've been able to expedite these things by connecting these pieces.
So we just want to examine that to see if that'll work.
DR. COHN: And I think you'd certainly want to examine it yourself.
MR. ROTHERMICH: That makes sense to me if that's the way people do – I'm not familiar with the ASTM standards.
DR. FRIEDMAN: Help me to understand –
DR. COHN: Okay – Maria?
DR. FRIEDMAN: -- what was just said. We have the standard that exists. We have industry practice today. So if we crosswalk the industry practice and it comports with the standard, then we're cool?
DR. COHN: Yeah.
DR. HUFF: Lucky!
DR. COHN: Though, one of the things we need to look at – once again, as I said, we're all – I mean, I'm flying blind on this one; I have not reviewed those standards for a number of years. I think many of them were actually initially developed by CPRI when CPRI used to exist as a separate organization. But that's been a number of years now.
So I think it's just a question we need to review it. Phil, I would certainly suggest you and NCPDP and others take a look at it. I always worry that sometimes some of these standards are at a high enough level that – well, I mean, it's just a worry that I have that one can get to a very high level of discussion where things are not specified, and I think we heard – I'm trying to think of who was yesterday who was describing that they had to spend a lot of time specifying how things actually would happen.
So it's one of the things that we'll just have to think about as we look at these. But without having looked at them, this is conjecture at this point.
MR. ROTHERMICH: I guess the thing I don't understand is to the extent this group is charged with recommending standards, if we're talking about an area where there are no standards, what then? And that's really why we took the approach we did, because if there are no standards and if ASTM has some, that's great, but if there are none, and there's a charge to recommend a standard, don't you have to create something to recommend?
MR. BLAIR: We could do kind of like what we did, is where RXHub had some messages that appeared to be well accepted in the industry and we simply encouraged that it go through the consensus process, and in this case, NCPDP appeared to be an accredited ANSI standards organization that would be the logical organization to transform that into an ANSI-accredited standard. So that was one thing that we did.
DR. COHN: If you remember back under HIPAA, obviously the Secretary's preference to use ANSI-accredited standards but if not, the Secretary reserved the right to develop their own if there were some compelling reason. I have to say as I think about standards, there's a couple of elements of standards that you just need to be aware of and I'm sure you weren't very familiar with.
One is the development of the standard, but there's also the maintenance. And I think most of us have felt that there needed to be some body that could not just come to consensus on the initial standard but that also was invested in – would develop Version 1.1 and 1.2 and 1.3 of that standard. Especially in the world of security, this is going to be a rapidly, as you know, evolving area and has been so far.
So it's a question of finding a home, and once again, I think most of us are convinced that the ANSI standards development organization and process is a pretty good process for not just to develop initial but ongoing maintenance, the evolution of these.
So I think that's where we've tried to be. But once again, security is a little different than everything else. Harry, do you have a comment?
MR. REYNOLDS: Yes, let me push it back to you a little bit about what you said.
The reason I asked the question initially was we've heard from the industry over and over again. You recommended the RXHub thing and you recommended NCPDP and you recommended and you recommended and you said, here's how we're doing business, and you continue to testify that this is all going on.
We couldn't get anything out of the industry today as to what you're doing in these boxes and whether or not you're using 40 different ways? Five different ways? Two different ways? Or you're all doing the same thing.
That's all I was pushing on, is to try to find out. And if you say there is no one way and if you say there's 400 ways and we've agreed to disagree, then obviously as a member of the Committee, I have to think about it. Whatever your answer is, I have to think about it appropriately because we have tried to work with the industry throughout this to see what you're doing because we've heard continually e-prescribing is going on and everything is happening. We're trying to formulate this.
So that's my whole purpose for the question, is give me a framework, if you're doing something that works.
MR. ROTHERMICH: Well, I guess I would beg to differ with you because I think you did today that the industry is doing essentially one way.
Now, there may be some variation in the detail, but the point of care vendors are all authenticating prescribers before they get access to the system. I mean, that's going on today. They're all using secure networks to transfer data.
MR. REYNOLDS: I don't want to debate it because I think I've made my point clear. But I think the point is: What is a secure network to you? What standards are you using to decide what a secure network is?
DR. COHN: I think Steve may be want to say –
DR. STEINDEL: Yes. Within the U.S., every time I've heard people talk about the issue of computer security, authentication or anything that revolves around it, it all goes back to base NIST documents. NIST is the primary source in this country for the levels of authentication that are used, the security systems that are used, the strength of encryption that is used, the encryption algorhythms that are being used.
And if you ever take a look at standards like ASTM or anyone else, you'll find that what they are just a collection of what NIST recommends. And, you know, we were handed the NIST document, the 75 pages, and it actually has that material enumerated in it in various places.
And then if you go back, as she mentioned, there's a thicker document that's associated with it, and a whole slew of other thicker documents associated from the NIST website describing this even further.
So what I'm concerned about actually is going to the direction of going to standard development organizations and asking them to codify what is standard business practice today, which is coming out of what they put together within their computer systems from the NIST system. And I believe that the way the security rule handles it in this very complex world is the best way to handle it, and that's do your assessments, state what you're doing, and be very clear about it and make sure it meets the need.
And I think if we go further with recommended a specific standard – you know, we can say that we recommend that we authenticate at this level, and maybe point to the NIST document or something like that, but I don't see how we can or should say how to do it.
MR. ROTHERMICH: Teri, you can speak to this better than I can, but I think the assumption when we talk about secure networks on this diagram, and I'm not nearly as familiar with it as you are, but that was sort of the assumption, that there is an industry standard for secure networks and that that's sort of baked in. And that's why we didn't get to the level of detail of what does a secure network mean.
MS. BYRNE: Yes. And this is Teri Byrne of RxHub. But just to address your point, Harry, we did talk about what we're doing specifically. We talked about the fact that we're using SSL encryption. We talked about the fact that we do direct lines.
So we did talk about some examples. We don't have just one that we use; we use multiple, depending on who we're talking with. And SureScripts and ProxyMed talked about the same thing.
So – but again, it does go back to we didn't want to specifically name anything because as soon as you name something, something better comes along and you want to follow the industry standards for what is secure.
MR. BROOK: One of the things – this is Richard Brook from ProxyMed – you know, it seems like we're talking about the standard registration process. It almost seems, at a very high level, all of us have the same unique ways that when we connect with point of care vendors, we know how this system operates with user name and password.
I was just talking to Lynne a second ago. I mean, if ASTM possibly has a standard way to the registration process and then the registration process between each entity, that might be something different.
Or, again, as you said before with NCPDP, we might want to come up with and make a recommendation again, but I don't know we'd be able to get this solved by January, 2006, a recommendation about a registration process, and I just think what Steve is saying – there's all these different things and how all the different networks and software. If we got into real detail, we'd end up having to bring SYSCO here and all the routers when a prescription touches.
I'm just saying I don't want to get to that point, Simon, but if you started to talk about how when you asked a question before, within the network – well, if you use SYSCO, use the NETS router. How is this stuff encrypted? How does it get there? And then we'd all fall asleep a lot sooner.
But anyway, but there are those points now, again, the standard operating ways that ProxyMed works, RXHub works, and SureScripts works.
DR. COHN: Lori, did you have a comment?
MS. REED-FOURQUET: Yes. Again, relative to both ASTM standards and ISO health informatics standards for security for the credentialing process, or the identification on binding of the individual to their identity, even though it's been defined in the context of PKI, you may want to take a look at the process that we defined as part of that, even if you're not going to consider the PKI because we do have ISO standards which are about to be full international standards and the ASTM 21, 22.
MR. BROOK: So what you're saying is we'd use the piece of that, the registration process not necessarily using the PKI, but to get from Point A to Point B.
MS. REED-FOURQUET: Yes.
DR. COHN: Margaret, do you have a – please. And then we'll try to wrap this one up.
MS. AMATAYAKUL: I've been taking notes here, and I just scrolled up and it says standards for the networks are out of scope. And now we're back talking about what standards we would recommend for the networks.
MR. BLAIR: They're out of scope.
[Laughter.]
DR. HUFF: And the reason it came up is because I disagreed, okay?
[Laughter.]
DR. HUFF: But in a way, I don't, so –
[Laughter.]
DR. HUFF: There's a level of standard that we can specify, but it's a level of mis-standard; it's not at the level of a particular implementation that you have to do. And so I think the only way we can make recommendations is in fact to point to standards. And I think the only disagreement is what level of standards really makes sense for us to point at.
We don't want to point at the level of standards that lock us into a particular technology or a particular vendor. We do want to point at standards that insure a certain level of functionality and I don't know the details to know what exactly we can say in that regard, or if we need to say anything, because we might be preempted by the DEA, so –
DR. COHN: Please introduce yourself and –
MR. SCHUETH: Tony Schueth, Point-of-Care Partners. Simon, I have a question and a comment. And I know it's running late, but I feel it's important that this question be asked today while Dr. Zuckerman and Lori are still here.
So my question is, there was a discrepancy in discussion on PKI. So Lori and Dr. Zuckerman strongly advocated PKI, and I went through the testimony – we've got DrFirst – there's four different pieces of testimony – ProxyMed, NCPDP and I'm not sure who this one is, but there's four different pieces of testimony that says that there are problems with PKI.
Reading from DrFirst, they talk about and they quote Thomas Sullivan, the past-president of the Massachusetts Medical Society; the AMA and its partner, and on its second partner have tried for several years to deploy PKI, and because of the complexity of maintaining the certificate and developing a successful business case, have not so far succeeded.
I don't want to get into the debate on this. I'm certainly not qualified to debate on this. But the question that I have for the Committee: How are you going to resolve the differences between these two testimonies?
MR. BLAIR: I don't think we can answer that right now.
DR. COHN: Yes, I'm actually trying to think of which differences – you mean between –
MR. SCHUETH: Well, you've got one group of industry advocates that are saying, you know, look, PKI is too expensive, it doesn't work, it's not the right thing for the industry right now; it will impede adoption.
And then you have two folks that testified later, at the end of today, that said this is something that we absolutely for several reasons.
And so my question just is: How are you going to resolve the difference?
DR. COHN: Okay. And I guess what we were doing was trying to take a different path or I guess what I think we're taking is a different path, which is beginning to look at the NIST documents and beginning to look at what we think the right level is for e-prescribing and working back from there, and then, at that point – I mean, we'll have to see if everybody else agrees, but sort of looking at it from that perspective with the idea of then backing into whatever technology and then recognizing the realities of the world today which may be that everything is being done
absolutely fine or that technology needs to be piloted or that something needs to be developed or whatever. But sort of trying to work that from the principled stand. I don't think at this point we have enough to – I mean, we've heard a lot today and yesterday that PKI was not ready. And I mean I think we heard a lot from that.
But I think we're all still sort of trying to figure out sort of the business case, the use case, where we need to be, if not next year, in three or four years. I mean, the question is, is there a business case to have PKI being piloted? Does there need to be more work on it?
These are questions that we're still asking but which we don't have any answers on. But I think we think as we come up with – I think as Harry was commenting when he says a 2 or 3 -- and how do we mitigate all that and what are the options? Maybe we'll all get a little smarter, and so I think we were going to think about doing some homework.
I mean, it's not much of an answer but it's really just sort of a reflection on the process and where we are at this point. Does that help?
MR. SCHUETH: That helps. Thank you.
So the last thing I just – I feel the need to comment on the fact that anything like this that's introduced into electronic prescribing, we need to look at
it from sort of a cost-benefit ratio and from my perspective, and I've explained that before, I just think adding additional cost right now with adoption it the way it is, I would strongly advise against doing that. That's my comment.
MR. ROTHERMICH: I just wanted to sort of ask a rhetorical question on the topic of maybe more research is needed, and it really goes back to Stan's question.
As I understand it, and I don't have a picture recollection of what the MMA says, but my recollection is there was a task given to create the innards for electronic prescribing with the idea that there's something ready to do by 1-1-06.
And I guess I'm wondering in the context of that statutory language, if when they said "standards," they meant ANSI-accredited standards or if they meant recommend a standard for e-prescribing and sort of a broader use of the word standard so that it's all done the same way.
And while I wouldn't debate the value of leveraging ANSI-accredited standards organizations, I guess I'm left scratching my head to the extent there are none, if the idea is to have something in place for 1-1-06 to say how is this system going to work? How do you do that without recommending standards for every piece of the chain? Again, it's not a question that has to be answered today, but –
DR. COHN: I'm really happy that Steve has his hand up, so, please.
DR. STEINDEL: There are some overriding government policies and practices, one of them coming from OMB, with regard to the standards process. And overall, unless we're told otherwise, the government is to look first to nationally accredited consensus standard development organizations as to what we should recommend for us.
MR. ROTHERMICH: I don't have any problem with that. I'm not debating it; I'm just saying when that's all and there's a charge to create standards, what do you do?
DR. STEINDEL: And it also states in there fairly clearly that if we find an area that we do need standards in, that first we should consider working with the standard development organizations to fill that hole. And the option that they sort of don't want us to do is fill the hole with a government standard.
So we do have a process that we do go through in our thoughts in filling holes that we find.
DR. HUFF: The only thing I would add to that is that the charge in the legislation to make the standards is a charge to HHS, not a charge to this Committee. So HHS might, in fact – if you went through that whole chain that
Steve just went through and in fact we needed standards that did not exist anywhere and couldn't be created, the charge to create those is to HHS in general, not to this Committee.
MR. ROTHERMICH: I guess the only place I was going is to the extent you heard consensus from the industry today on what standards for those kinds of things ought to look like, it strikes me that it makes sense to include it in the recommendation.
DR. HUFF: Yes – I mean, the thing that we could do, I think, appropriately is say – recommend to HHS that a standard be developed along these lines or whatever.
MR. ROTHERMICH: That's a sense of ours.
DR. COHN: I think Karen's going to reflect probably the fact that it actually isn't HHS; it's probably us – but please.
MS. TRUDEL: No, actually I'm hoping I can put this to bed with some statutory language.
DR. COHN: Oh, that would be good, good!
[Laughter.]
MS. TRUDEL: I never leave home without this!
The MMA actually says two things. In terms of the role of the NCVHS, it says the National Committee shall develop recommendations for uniform standards. With respect to the Secretary's authority, the statute says the
Secretary shall develop, adopt, recognize, or modify additional uniform standards. So it gives the Secretary a certain amount of leeway.
However, when you look at that in the context that Steve just drew, which is government-wide and bolstered our experience with HIPAA and CHI, you see that there's a very logical progression here and that it makes a lot of sense to do things the way the subcommittee's been doing them.
DR. COHN: And Phil, I think I'll go back to my earlier comments about the standards piece. And as I said, it isn't just development, it's also maintenance, which are really key issues as we sort of move forward.
Now, I don't think anything that the subcommittee or full Committee might say will prevent you from working with NCPDP around the issues of security, and I actually suspect that NCPDP has a relatively robust area already in reflecting on some of these things.
I think what we are saying is that probably the first step, though, for all of us to review the various ASTM documents, the NIST document or whatever before you start plotting a course. And that was really, I think, the view at least that I have. It just seemed premature to start running north where maybe something else already else that would do. And so that was really, I think, the reflections that we've had. And so once again it's one of those frustrating areas that we are actually in the middle of process. We are not coming to recommendations today. We're talking about issues, things that we need to study more, recognition that there needs to be some next steps and not firm answers.
So I really do want to emphasize that.
MR. ROTHERMICH: I won't belabor it any longer.
DR. COHN: No, that's fine. I mean – we still have tomorrow; don't worry. Alan?
DR. ZUCKERMAN: There is one more standards development organization I haven't heard mentioned too much today regarding digital signature, and again that's the WACO, the World Wide Web Consortium. And a lot of the ASTM standards, others much like the NIST documents, also go back to the WACO as a very important primary source of information. And they have, I believe, it's now from 2002, a standard for PKI digital signature and XML.
And should we move forward with something like this, I believe the feeling at ASTM is that we would implement their particular technical method.
But again, the reason you hear such diversity from the vendors today has been very well identified. Until we hear from the DEA, we're really paralyzed in having an understanding of the cost and the practical realities of doing anything about digital signature.
So that's really an essential first step that will probably very quickly bring consensus in the industry by setting a standard that people can't walk away from.
DR. COHN: Judy – please.
DR. WARREN: Well, I was just responding to Alan because one of the things that I was trying to get at earlier today when Walgreen's and Albertson's – we kept hearing testimony about we need to have the pharmacist feel comfortable the prescription has been authenticated.
And so what I may be thinking from Harry's questions and now from what Alan is saying is maybe we need to identify some of these standards that will assure and make people comfortable, that this really is, has been untampered, so some of the secure socket stuff and all that. Maybe not so much that they're mandated, but identify them in a dialogue in our recommendations that what our recommendations are based on is the existence of these more sub-foundational standards or whatever.
And that might help us kind of close the snap when we get uncomfortable. It seems to me it really is that this more general standards layer, that everybody that's doing business on the Web is having to deal with.
DR. COHN: I sense that Phil wants to make another comment.
MR. ROTHERMICH: Again, just to your comment. I think it's important to remember the difference between security and authentication because a lot of your comment was about security but you started off talking about what the pharmacists were talking about and their primary concern, given their confidence in the security that exists today, is authentication.
And authentication in this context isn't really about signature because if you remember, eSign as legislation was about contract law, about intent to be bound. And signing a prescription isn't intending to be bound; signing a prescription is clearly for authentication, meaning I the physician want the patient to have this drug. And it's a subtle distinction but it's very important because it's really not about the signature. It's about making sure the physician intends, the person that you think intends, to have a certain patient have a drug.
So it's not all about just a signature and whether it's an electronic signature or digital signature; it's about authenticating that that physician that you think is on the other end wants this patient to have that drug. And there's lots of ways to do that. And so the signature almost becomes secondary.
DR. COHN: All right. A new point. Steve?
DR. STEINDEL: I was just muttering I think what Simon just muttered underneath. That's a nice articulation of what we are really dealing with in this area of e-signature with respect to e-prescribing and that it is a slightly different piece than we talk about e-signature in the contract world and a legally binding document between two people et cetera, and I thank you for enunciating it.
MR. ROTHERMICH: Well, and the reason I'm beating it to death is because I'm concerned if there's a feeling that if there aren't a standard, we can't go there or we don't have to go there because to make e-prescribing work, to make adoption take off, you've got to have, first, a single way of doing it, which is the preemption piece, but also a way to make the pharmacist comfortable that we know who's on the other end.
And to me, for that, you've got to create, recommend, however it gets to be a standard, you've got to have a way for everybody to do it so people feel comfortable and it can take off.
DR. COHN: Very well said. Okay, now is that the last word? Okay. That's unusual for this committee to be at a loss for words, but –
MR. REYNOLDS: No, we decided to stop, Simon. We're not at a loss for words.
[Laughter.]
DR. COHN: Okay. Now it is 5:45. Now we have – the meeting starts at 8:30 tomorrow and we'll start out again and we will start out with an update, after introductions, on HIPAA and discussion.
John Paul Houston will be calling in as we talk somewhat about the security role. A very appropriate introduction this afternoon to that.
And then we'll be talking about some of the work that NCPDP has sort of been sponsoring with the industry to sort of improve the e-prescribing standards.
And then I'm presuming we'll have some additional thoughts on some of these other pieces as we do sort of a final discussion about planning for the next set of hearings.
So thank you all, and we'll see you at 8:30 in the morning.
[Meeting adjourned at 5:45 p.m. until the following day.]