[This Transcript is Unedited]
Hubert H. Humphrey Building
200 Independence Avenue, SW
Washington, D.C.
Agenda Item: Call to Order
DR. COHN: Good morning. I want to call this meeting to order.
This is the first day of two days of hearings of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics. The committee is the main public advisory committee to the U.S. Department of Health and Human Services on National Health Information Policy.
I am Simon Cohn, Chairman of the Subcommittee and 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 do want to, as always, welcome those listening in on the internet.
I obviously want to remind everyone today – and will, I'm sure, remind everybody a number of times - to speak clearly and into the microphone, and we have had a long history of these microphones being little finicky. So I just warn our presenters.
Obviously, there is a lot of work over the next two days.
Today, the subcommittee continues our hearings on e-prescribing standards.
There is actually going to be a little bit of change in the agenda in the sense that we are flipping the first two presentations. Our first presentation today will be from the Drug Enforcement Administration, and then, from there, we are going back and having a CMS update on e-prescribing.
Then from there we move into an overview of the DEA/VA pilot this morning.
After lunch we are going to be hearing from a number of representatives from the industry, and then, after the afternoon break, we'll be hearing from NIST about their framework and standards as well as ASTM and their standards work.
Now, at the end of the day, we are going to be having open microphone and then going to subcommittee discussions.
As always, I want to emphasize that this is an open session. Those in attendance are welcome to make brief remarks if you have information pertinent to the subject being discussed.
We will also have time at the end of the afternoon for brief comments by those in attendance.
Finally, for those on the internet, we do welcome emails and letters on any of these issues coming before us either today or tomorrow.
Now, just to remind you, tomorrow, we do start at 9:00 a.m. We'll be talking primarily about HIPAA. We are starting out with, I think, a briefing from the work group on Electronic Data Interchange and then moving from there to an update from the NUCC and the NUBC.
We will also be discussing plans for the next hearings in February and other issues that need to come before us in 2005.
Now, with that, let's have introductions around the table and around the room, and 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?
Maria.
MS. FRIEDMAN: Thank you, Simon.
I am Maria Friedman from the Centers for Medicare and Medicaid Services, and I am the lead staff to the subcommittee.
DR. WARREN: I'm Judith Warren from the University of Kansas School of Nursing, a member of the committee, and I don't have any conflicts that I am aware of.
MR. REYNOLDS: Harry Reynolds, Blue Cross and Blue Shield of North Carolina, a member of the committee and no conflicts.
MS. TRUDEL: Karen Trudel, Centers for Medicare and Medicaid Services, staff to the subcommittee.
MS. BEBEE: Suzie Bebee, ASPE, staff to the subcommittee.
MS. AMATAYAKUL: Margret Amatayakul, contractor to the subcommittee.
MR. MAPES: Mike Mapes with Drug Enforcement Administration.
DR. LEVIN: Randy Levin, Food and Drug Administration, liaison to the subcommittee.
DR. FERRER: Jorge Ferrer Veterans Health Administration, staff to the subcommittee.
DR. HUFF: Stan Huff with the University of Utah and Intermountain Health Care in Salt Lake City, a member of the committee and of the subcommittee, and I don't think I have any conflicts with anything that we are testifying about today.
DR. STEINDEL: Steve Steindel, Centers for Disease Control and Prevention, staff to the subcommittee and liaison to the full committee.
MR. BLAIR: Jeff Blair, Vice President, Medical Records Institute.
Related to any discussions on ASTM, I would be recusing myself from voting.
MS. FERIDA: Michelle Ferida(?), Drug Enforcement Administration.
MR. BRUCK: Steve Bruck(?), PEC Solutions, supporting DEA.
MR. POLLARD: Michael Pollard(?), Medco Health Solutions.
MR. SIMKO: Mike Simko, Walgreens.
MS. GILBERTSON: Lynne Gilbertson, National Council for Prescription Drug Programs.
MR. RATHER: Phil Rather - Express Groups.
MR. DE CARLO: Michael DeCarlo, Blue Cross, Blue Shield Association.
MR. GUINAN: Jack Guinan, ProxyMed.
MR. LEVINE: Gary Levine, Senior Director of Electronic Prescribing for Mental Health Solutions.
MS. HOFFMAN: Ruth Hoffman with Pharma.
MR. NEWMAN: Mike Newman(?), Health Resources and Services Administration.
DR. ZUCKERMAN: Alan Zuckerman, American Academy of Pediatrics, representative to ASTM. I teach and practice at Georgetown University, School of Medicine.
MR. WOODIMORE: Ken Woodimore(?), SureScripts.
MS. AGNASTIADES: Alania Agnastiades(?), National Association of Boards of Pharmacy.
MS. WILLIAMSON: Michelle Williamson, National Center for Health Statistics, CDC.
MS. FORD: Cheryl Ford, Centers for Medicare, Medicaid Services.
MS. HOWARD: Cynthia Howard, Centers for Medicare and Medicaid Services.
MR. NIAK: Rohick Niak(?), Vice President, MedPlus.
DR. COHN: Okay. Well, I want to welcome everyone.
Now, before we start our first briefing, I actually do want to just take a moment and thank Jeff Blair, our Vice Chair, for his work sort of moving this agenda forward, and, obviously, also Maria for tremendous efforts in terms of putting together these and other hearings on this topic. So thank you both.
Jeff, do you have any comments to make before we launch into the first session today?
MR. BLAIR: No, just wanted to thank our testifiers for being here, that's all.
DR. COHN: Yes. Yes.
Agenda Item: EPCS Program Update
DR. COHN: And I think we'll turn to our first briefing.
Want to thank you, obviously, for your flexibility in allowing us to sort of switch you around from second to first on today's agenda, so thank you.
MR. MAPES: Okay. You're welcome.
Good morning, ladies and gentlemen. Thank you for giving us the opportunity to meet and discuss this issue that is of importance to all of us this morning.
I'm Mike Mapes. I'm the Chief of the E-Commerce Section for the Drug Enforcement Administration, Office of Diversion Control, and we are going to talk about where we are with what we call EPCS, our Electronic Prescriptions for Controlled Substances Program.
As probably everybody understands, the Drug Enforcement Administration deals just with controlled substances, and controlled substances are a small part of the overall pharmaceutical drugs that are handled in pharmacies, maybe 5-10 percent, depending on the practice setting.
Our controlled substances, as you'll see in the program, are divided in five schedules, Schedules I through V.
Schedule I, obviously, those are the drugs that do not have a legitimate medical need or use in the United States. So you won't be seeing those in the prescription world. Those are mostly in the research world.
But then Schedule II through V are the other controlled substances that are handled by pharmacies and prescribed by the practitioners, with Schedule II being those that have the highest potential for abuse and still have an accepted medical use in the United States.
But our concern is the abuse of those drugs, and there's a serious abuse problem for a lot of the drugs, including the Schedule II's, and one of the big parts of DEA is making sure that we have a sufficient supply of those drugs available for legitimate medical purposes while not having enough around so they can be diverted and abused, rather than used for the intended purposes.
So, in order to help us with that, the Controlled Substances Act, the CSA, mandates that DEA control the registration of anyone who handles controlled substances. So whether it be a pharmacy, a doctor, a manufacturer, an importer, exporter, any of those kind of folks, they are registered with DEA, and the dispensing of the controlled substances, to be sure that they are done using a legitimate medical purpose and using established standards, and that if it is by prescription, it has to be signed by the prescriber.
DEA legal authority comes from the Controlled Substances Act, and then we have other considerations, the Government Paperwork Elimination Act, and we looked at our - when we looked at GPEA, we looked at that our current requirements are that Schedule II's must be written, with very few exceptions. Schedule III, IV and V can be either written or oral.
And then the other project that we have that is related to this is a project that we call CSOS, and that deals with the orders that retail pharmacies place with their distributors or the distributors with the manufacturers.
For Schedule II's, right now, they use a DEA-issued paper form and that is a project, the CSOS project, that is very similar to the EPCS in that that will be a PKI project, and that is further along, and we have gone through the rule-making process, and we are getting ready to have that one out in final form in the near future and we'll be starting that. So you'll probably be hearing a little bit about that at the same time, and we use the same infrastructure for both projects.
CSOS and EPCS allow the registrants to satisfy the prescription - or the order requirements, in the case of CSOS - electronically, rather than sending paper back and forth, and allow DEA a means to enforce the requirements that we have for control over the controlled substances.
All of these projects that we have are funded through a fund called the Diversion-Control Fee Account. The Diversion-Control Fee Account is the funds that doctors, pharmacies, hospitals, everyone pay for the registration with DEA. So the funds that people pay to be registered with DEA is what is paying for these projects.
When we looked at the requirements for electronic signature in the very beginning, trying to determine what our requirements were, we had to look at legal sufficiency. We had to look and see if the signature that would be used would be sufficient, if the person writing the prescription, signing the order for drugs was charged in an administrative setting, a civil setting or there was a criminal prosecution of that person, and so we are always concerned to be sure that the signature is sufficient legally, if we get into that kind of a situation, and that there is authentication and a non-repudiation integrity of the information that is used, it is accountable and it is a really strong record of the transaction that we can go back to later.
With respect to the responsibilities of the pharmacy, DEA registrants face significant liability associated with their responsibility to validate the authentity(?) of a controlled-substance prescription or a supply-chain order, and companies can face fines and be criminally prosecuted if it was done intentionally. These relying parties currently are not well equipped to validate the integrity nor the authentity of the transactions because they are using paper-based systems.
DEA's EPCS program will provide registrants with the information they need to make accurate decisions regarding the authorization and status of the practitioner - by status, we mean, do they have a DEA registration that is in the appropriate schedules for the drug that is being prescribed - and the integrity of the electronically-transmitted controlled-substance prescription. So that information will be provided to the pharmacist to help them make their decision.
When we look at the number of individuals that could be involved in either of these projects, the Electronic Prescriptions for Controlled Substances, there's about one million DEA-registered practitioners, people authorized to prescribe controlled substances, that is the range, from the traditional doctor to physician's assistants, nurse practitioners, those kind of folks, if they have prescriptive authority in the state that they are from, and they prescribe about 600 million controlled-substance prescriptions in a year.
The other project, the Controlled Substance Ordering System, there's about 200,000 people who may have a digital certificate for that and there might be about seven million transactions that they do in a year.
We are not mandating, in either case, that people adopt the electronic system. We are offering it as an alternative. So they can still use a paper-based system, if that is their desire.
DEA is working with GSA to design EPCS, so certificates used by DEA for the controlled-substance prescriptions could be used for other government transactions, at the discretion of the registrant. This could be relevant to administrative transactions as well as Homeland Security-related systems.
To enable this, DEA plans to cross certify with the Federal Bridge Certificate Authority. This cross certification would be performed in one direction, thereby allowing other federal agencies to trust DEA certificates for their transactions, but preventing other certificates from being used for prescriptions, and the reason that we have done that, generally, is that our certificates will provide identity as everybody's digital certificates do, but they'll also provide the credentialing part of their DEA registration, and other folks don't have that in their certificates.
We have coordinated with many different government agencies at many levels in many meetings and discussed these issues related to both the prescription and the electronic orders.
With NIST, we have discussed the certificate policy and the profile, revised architecture and discussed with them revisions to the architecture. We have talked with the folks about FIPS and how that plays into the system.
With GSA, with the FICC and Initial Mapping to the Federal Bridge Certificate Authority and the E–Authentication.
We have discussed, briefly, with the Department of Veterans Affairs, and they have a - using their system, VISTA, to PK-enable it so that they can use this.
We have discussed with SSA, very briefly, about using this to make suitability determinations, and we have talked with HHS, the CMS folks, made a presentation with them about where we were and where we are going and what we are doing with the system, so that we have been trying to get everybody's input and take that into consideration.
We have coordinated with a number of associations and industry groups.
We have been actively piloting the EPCS program.
The VA is currently piloting digitally-signed e-prescriptions at the Hines Illinois Medical Center. DEA operates a test system in support of the registrants who are participating in the pilot system, the other CSOS pilot, with HDMA and NACDS.
The success of our strategy of coordinating with, discussing with everyone that we can these - our proposed systems has been demonstrated by the fact that numerous EDI and EDI vendors have invested to develop DEA-compliant commercial, off-the-shelf products, and in our supply-chain project, the CSOS project that is coming up to start use in the next few months, there are several COTS products that have been developed that are compliant with our requirements.
Our experience with CSOS with applying EDI and EDI 850 has been positive and leads us to believe that the solutions to PKI-enabled prescriptions should be within the reach of the PKI system also.
After five years of working with the industry, DEA is ready to bring in a production in the supply-chain program that has been sought after by the industry for a long time, and we'll be using that same approach working with the industry to come up with final rules in the ECPS project.
I would like to talk just a couple of minutes about the EPCS performance standards. These are the four critical factors, the authentication, the interoperability, the scalability and the control of the system, and it is our belief that the integrity and non-repudiation cannot be accomplished without digital-signature technology, and regardless whether the system is closed or open, this technology will allow it to meet DEA's law-enforcement requirements and dealing with controlled-substance prescriptions.
In June of 2003, DEA issued an EPCS Request for Information, RFI, to solicit input from the industry. The purpose of the RFI was to obtain industry input regarding the best model for DEA's PKI, whether that be a hierarchical or a bridge PKI.
DEA received 10 responses to their RFI from a number of PKI and healthcare technology companies, and based on that input and a consultation with staff from GSA and NIST, DEA adjusted its course and it is now working to establish a more flexible federated model based on - certification and PKI bridging. This approach was selected to enable DEA to out source certificate management responsibilities to the effective industry. In effect, DEA will approve industry CA's that meet DEA and federal requirements to issue certificates to the over one million DEA registered practitioners.
DEA has worked closely with the U.S. Federal Identity Credentialing Committee and the National Institutes of Standards and Technology to ensure that the federated approach leveraged industry CA's to the maximum extent possible without compromising DEA's security requirements.
DEA's approach to implementing EPCS is founded on government and industry standards that are mature and, equally important, commercially available. These standards must be viewed in two areas, this trust infrastructure the DEA will establish to issue electronic credentials or digital certificates to registrants, and, two, the applications that are enabled to provide the security services offered by PKI technology, namely authentication integrity and non-repudiation services that meet DEA's anticipated standards.
Since the supply chain and prescription applications typically EDI technology has used are owned and operated by industry and not by DEA, combining identity and authorization within the certificate is the only effective method for mitigating the considerable risks faced by the companies. Any other approach would not reduce the industry's risk and would, therefore, not be widely adopted. This outcome would represent the least-favorable return on OD and the department's IT investment.
It is important to note that DEA considered and purposely avoided architectures that are based on identity-only digital certificates. This was done in order to minimize government involvement in high-value healthcare transactions since identity - all the new models of this type would require industry to access a government-operated authorization database, a situation where DEA downtime would be intolerable.
DEA resolves this issue in its anticipated regulations by purposely allowing the industry to cash(?) revocation lists. This allowance is a key element of DEA's reliability and availability architecture.
In addition, the DEA issued digital certificate serves as a DEA issued form which the statute mandates.
The DEA Bridge Certificate Authority is used to be sure that we are aligned with the other federal initiatives and we establish a certificate policy that defines the obligations and standards for all the registrants - the approved CA's, the practitioners, the pharmacies and the e-prescription system vendors.
The obligations of the CA are to operate in accordance with our certificate policy, the EPCS certificate policy, issue digital certificates only to DEA registrants, perform revocations required and publish revocation information every four hours, undergo an annual audit for approved status and that the audit would be performed by an outside organization.
The core policy provisions in our certificate policy deal with the identification and authentication of the individuals that would receive the certificate, the CRL frequency, the CRL checking requirements, physical security, the use of biometric, the expiration date of the certificates and the extensions within the certificates.
It is important to remember that the EPCS is application neutral and its transmission is standard neutral. DEA is neither requiring a specific content or message format. We do not make any stipulation regarding transport. Our anticipated standards only address security standards that we believe are necessary to protect these transactions. We do want to see the certificate transmitted along with the transaction. With respect to system implementation, COTS products that have been in support of this, whether they are email or EDI NT(?).
The FIPS security standards, DEA has worked closely with the National Institute of Standards and Technologies to identify and include those federal information processing standards to ensure that DEA's performance standards do not introduce new vulnerabilities.
The security requirements cover areas related to security design and implementation of cryptographic modules. The FIPS standards combined with NIST's Cryptographic Module Validation Program enable industry to verify that security applications meet basic crypto and performance standards.
The goal of the Cryptographic Module Validation Program is to promote the use of validated cryptographic modules and provide federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules.
All this is really critical importance to us, because we have learned from NIST a significant percentage of all the products that they evaluated are initially found to have vulnerabilities. These tests ensure the performance standards are met in a reliable fashion.
DEA has worked closely with state organizations to identify the security requirements that they believe should be part of the system. At this time, DEA expects to include biometrics in the notice of proposed rule making for electronic prescriptions.
DEA expects that we will get a significant response on this particular topic. It is something that we know is being watched closely by all the parties involved, and we are interested in getting the comments from everyone so that we can make an informed decision as the process goes along.
The required prescription content remains the same as it does for a paper prescription - the date of the prescription, the patient name and address, the drug name and strength and dosage form, quantity prescribed, directions for use and the practitioner's name, address and DEA registration number.
In the electronic world, this data needs to be archived and must be readily retrievable in the electronic form.
Application compliance auditing. The initial compliance audit is required for all EPCS-enabled applications and followup audits will be required upon major application revision.
In softwares, the pharmacies will be required to ensure that their software complies with the requirements. It is not a site-specific audit.
The pharmacy obligations, the pharmacies, the pharmacist will not require an EPCS digital certificate for the EPCS system. They would require a CSOS digital certificate if they were electronically ordering things from their wholesaler.
Prescription validity is based upon the validity of the digital certificate at the time of the signing, and refills are based upon the validity of the original prescription.
The pharmacy software performs several checks. It checks the digital certificate to see if it is valid. It checks the practitioner's digital certificate to see if it has expired. It checks the issuing CA's digital certificate to see if it's expired or if either of those certificates has been revoked, and it checks the institution's digital certificate if the prescriber is an agent of an institution. It checks the prescription integrity to see if the prescription has been altered in transmission, and it leverages the trusted digital certificate to check if the practitioner has the authority to prescribe the schedule listed or to see if the practitioner is an agent of a specific institution.
Related to pharmacy record keeping, the pharmacist must electronically sign the prescription. E-signature performed as a separate act in the process. The access code/PIN is an acceptable solution in this process, and they must maintain an electronic archive of the prescription for two years, which is the same retention requirement we have for paper-controlled substance prescription.
And the software audit for DEA compliance is not a site audit for each pharmacy. It is for the software itself.
The Veterans Administration pilot test, DEA established an MOU with Veterans Administration to allow a limited pilot in the Hines, Illinois Medical Center. Understand that Rob Silverman from the VA will be addressing the panel on the outcome of this pilot later today.
From the DEA's perspective, we feel the pilot has been successful for a number of reasons. While we did not use biometric activation, smartcards were able to demonstrate PKI to PKI interoperability between the DEA's CA and the Verisign CA. So the certificates that the VA is issuing are, in fact, from an industry CA, which is the direction that we are heading with the project. Also, the VA was able to demonstrate essentially a smart application that could select the appropriate certificate from a practitioner's smartcard. This is a solution where VA employees have their own certificate and the participating practitioners were also issued a DEA compliance certificate. The application was able to read the certificate on the practitioner's smartcard and select the appropriate certificate for use in the prescription situation.
Under these circumstances, it is unusual for a smartcard to protect all stored credentials with the same activation password. So this is not a situation where the doctor had to remember multiple passwords for separate credentials.
The VA test in Hines was for a Schedule II prescription. It was using VA's Verisign CA as a sub CA. The VA issued practitioner test certificates, and there were 18 or more practitioners, and, at last word, over 800 prescriptions had been transmitted using the system at that hospital.
A little bit about the economic impact analysis that was done as part of the rule-making process, some of the considerations that we had to look at when we were talking about the prescription cost estimates. We are looking at the paper prescription on the left side. The time required to sign it, fax it, phone it, the number of call backs, the cost of prescription forms, the cost to enter data, record keeping, storage, waiting time.
And then, on the right side, in the digital prescription, looking at that cost, the cost to obtain/renew signatures, to acquire and install systems, the time and effort to learn to use the systems, the time to sign and transmit and the cost of validating and annotating records were all factors that were considered in the overall cost.
What we found with it is that the current system comes up with about $250,000 per pharmacy per year. In the digital system, could be as little as $26,000 per pharmacy per year; and the cost per practitioner per year, with the current system, about $25,000 to $69,000; and the cost for a practitioner using the digital system, $4,000 to $12,000; and the total cost for all the practitioners, about $4.5 billion a year, $7.3 billion if you include the public waiting time that could be reduced using the current system or about $773 million a year using the digital system.
We looked at the annualized cost over 10 years. In the current annualized cost of over 10 years, about $6 billion. With digital, it could be about $2.5 billion, as adoption is phased in, with a significant cost savings and, hopefully, reduction in the amount of diversion of controlled substances, also.
Our recommendations are that for electronic prescriptions of controlled substances that it be a PKI-based digital signature is required for electronically-transmitted prescriptions and orders. The biometrics could be a part of this solution, and the third is that DEA is willing to participate with any organizations that have an interest in this to further discuss the situation and as we go down the road in creating the new rules and procedures for this.
And if you have more questions after this, there's names and phone numbers. Give us a call.
DR. COHN: Well, Michael, thank you very much for, I think, what has been a very useful briefing for the subcommittee and I really - appreciate your - the amount of information you have been willing to share, knowing - as I understand, this is obviously a direction that the DEA is proposing, but has really not even started moving through regulatory processes or anything like that. So –
MR. MAPES: We have started moving through the regulatory process. We have drafted a Notice of Proposed Rule Making. That was in process at the Office of Management and Budget. We withdrew that so that we could get some more discussions with industry and other interested parties, so that we will meet with more folks to get some other ideas and then, after we get those, we'll put that back through the process again.
DR. COHN: Okay. Well, thank you for that clarification, and, obviously, I just want to remind both the subcommittee and others listening in to all of this, the role of this subcommittee, now, clearly, just want to remind everyone that we are advisory and advisory to the U.S. Department of Health and Human Services. So we are not advisory to the Department of Justice and the Drug Enforcement Administration, but, on the other hand, obviously, we can ask the Secretary of HHS to talk with the Attorney General or your agency head, and, obviously, our interest and involvement in all of this, I think, as you know, that under the Medicare Modernization Act, e-prescribing, as part of Part D, is intended to be a major sort of policy and interest and desire both from the industry as well as the Centers for Medicare and Medicaid Services. So we are trying, obviously, to advise them.
We have obviously heard a lot of testimony I think sort of asking questions about the level of authentification and non-repudiation that is really required for this, and we obviously are well aware that narcotics, while not the only business case for how all this works - I mean, clearly, DEA has a major interest, and we want to make sure that whatever we do really does link up appropriately.
So I think, obviously, we are happy to begin this conversation, and I am not at all certain we are going to finish it today, but I think we'll at least begin it.
Now, with that, I'm sure the - the subcommittee has questions. I actually maybe would start myself with just a question or two, and I guess I was - we have had a lot of testimony, and I did notice during your testimony that you made a comment about open versus closed systems, and you, I think, felt that the non-repudiation and authentication requirements for both are virtually the same, and I wanted you just to talk about that a little bit, because I think we have heard from some that there's - with the amount of security that occurs with a closed system that it may be a mitigating factor for some of these other issues. Can you comment on that?
MR. MAPES: Yes, first, I would like to make one general comment and that is that I'll answer the questions the best I can. If we get in an area that may be too technical, we would like to just give you some written comments later about those -
DR. COHN: Please.
MR. MAPES: - but in relation to your question, in the closed system, we still have to ensure that there is the same level of non-repudiation, the same level of trust that there would be in an open system. We'll say it's a - the VA, for example, is a closed system. They use their system, as opposed to someone who is using the internet to send the electronic prescription. So we have to have one set of standards that is technology neutral that applies to all situations, and that is part of our challenge is finding a single standard that we can stay with for a long period, because while PKI seems to be the solution at the present time, as technology changes, there may be other solutions out there that provide the same security and non-repudiation that PKI now does. So we are not closing the door on any of those. We are trying to develop our regulations and standards so that they are completely neutral as to technology and if there is a technology that can meet those standards that we could then allow that technology to be used.
DR. COHN: Okay. I think, Jeff, you had a question. I'm sure I have a couple of others and are there -
MR. BLAIR: Oh, sure.
I need a little bit of help, and although this question is obviously directed at you because you are testifying right now, if there is anyone else in the room that could clarify this as well, I don't want to preclude them from also clarifying this.
The topic of non-repudiation, in my mind, seems to require two types of security. One is that the document that is being - in this case, it would be a prescription - that that document hasn't been tampered with, and, number two, that it is bound to the signature, and, then, in addition to those - that is, you know, verifying that the document or other prescription is received without being tampered and it's bound to the signature - and then the second is that the individual who is sending the prescription is authenticated or certified that that is, in fact, the individual that they claim to be. So, in a sense, there's those three requirements. Is that your definition of non-repudiation?
And let me just indicate that part of the thrust, the thinking behind my question is that I am wondering if if there's other ways of assuring that the document hasn't been tampered with, I'm wondering whether we need to stay with the definition of the word non-repudiation or can we be working with the component pieces in order to figure out what is the appropriate level of security that is needed.
So do we need all those three levels for non- - those three functions for non-repudiation?
MR. MAPES: When we are discussing non-repudiation, we are talking about that the individual who signed the document electronically cannot come back later and successfully claim that they did not sign that document. The non-repudiation - the other parts that you talked - that the document has not been changed, that is the integrity of the document as opposed to the non-repudiation, a slight difference, but we have set those out a little bit differently. And then the certification part is that, as we talked before, our digital certificate will offer identity of the person, so that the relying party - the pharmacist, in this case - will be able to say, yes, this did come from the doctor whose name we have, and the credential part of it, that that doctor is registered with DEA to handle, prescribe this schedule of controlled substances. So there are really three separate and distinct things. The non-repudiation just deals with the fact that the person who wrote the prescription in this case cannot deny it, cannot repudiate that they had done that.
MR. BLAIR: Okay. Then given that definition of non-repudiation, where you seem to separate off the portion of security which would deal with ensuring that the document hasn't been altered and that it's bound to the signature, you indicated that is data integrity as opposed to part of non-repudiation. Is that correct?
MR. MAPES: Yes.
MR. BLAIR: Then my next question is if that is the case, you indicated that if the document is sent over a secure network, what requirement do you have when it is over a secure network? And that may be - we may have to get into a definition of what is a secure network, but if it is in a secure network, what requirements do you have to ensure data integrity?
MR. MAPES: Our requirements do not include the transmission requirements. Our requirements are what is contained in the prescription and the infrastructure that we are putting together to allow that to be transmitted, and we have to be very consistent with our requirements in the paper world, and we don't have transmission requirements, a similar requirement for a paper prescription. We say that it can be oral. It can be faxed, in some situations. It can be written and carried by the person to the pharmacy from the prescriber. So ours are not transmission requirements.
DR. COHN: Okay. And, Jeff, I think I was asking some of the same questions, only I was using open versus closed, which - I mean, I guess I had presumed closed meant secure.
MR. MAPES: Right.
DR. COHN: At least that was what I - I mean, that may be how you were answering it also.
MR. MAPES: Yes.
DR. COHN: So just interesting terminologies.
Steve, Harry, and then I think I have another question.
DR. STEINDEL: Yes, thank you. Thank you for the interesting presentation on the directions, and, again, like Jeff, we have been hearing a lot about this area of electronic signature, et cetera, and a lot of terminology issues with it over the last few weeks in hearings.
I have a couple of questions for you.
First of all, your statement was that about - I think it was about 5 percent of the prescription orders, maybe 5 to 10 percent, were for controlled substances, and we have heard from other people that is 15 to 30 percent.
MR. MAPES: Okay. I guess it depends on the practice setting that you are in, what kind of pharmacy you are in, whether it is the mail-order pharmacy or a retail pharmacy, a hospital. It is a small percentage of the total volume of prescription drugs, and whether it is 5, 10, 15 or 20 percent, it is a minority of those prescriptions.
DR. STEINDEL: I noticed in the VA pilot you limited it to Schedule II drugs. Are you planning on, when you release this as a full system, to just limit it to Schedule II drugs or to extend it through Schedule V drugs?
MR. MAPES: No, we'll allow it for all controlled substances, and if someone wanted to use the system for other than controlled substances, they could, at their discretion. That would be at the discretion of the holder of the digital certificate, the prescriber.
DR. STEINDEL: So as I interpret that, if people were using the Medicare Part D system, the electronic prescribing for Medicare Part D drugs, they would be required to use your system to electronically prescribe Schedule II to V drugs.
MR. MAPES: No, the requirement is only for Schedule II. There is an allowance for others, but if - Schedule III, IV and V do not need to be handled in the same way as Schedule II does.
DR. STEINDEL: So this PKI system that you are envisioning would be just limited to Schedule II?
MR. MAPES: No, it would be allowed for all, but if someone was going to use Schedule II's, they would be using this system.
DR. STEINDEL: Could they - if we were in a total electronic prescribing world and someone wanted to prescribe a Schedule III drug, could they use some other type of electronic prescribing system with another form of security, non-repudiation, et cetera, besides what you are requiring?
MR. MAPES: They may be able to. It would end up looking at what the final standards would be in the regulations.
DR. STEINDEL: Okay. Because that issue has been raised multiple times here -
MR. MAPES: Right.
DR. STEINDEL: - about some acceptance for limiting this to Schedule II drugs, but would prefer, as exists now in the paper world, a little bit of leeway for maybe the III to V drugs. So I find your answer -
MR. MAPES: We understand the differentiation between the two, and there may be a different situation in those.
DR. STEINDEL: Yes, thank you for that clarification.
Another question I had concerned - I was a little bit confused on certification, the issuing of the certs. You said that the DEA cert will work over a bridge so you could use it for federal - other federal programs, but you would not go the other way where a certificate that appeared to be issued by another group would be accepted by the DEA, and then you talked about private-sector certification. You know, if a private-sector cert met your requirements, could you use it in both - internally into DEA?
MR. MAPES: We would expect that those issuing digital certificates in the ECPS program would be other government agencies. It could be boards of pharmacy –
DR. STEINDEL: Um-hum.
MR. MAPES: - things like that, boards of medicine. It could be associations. It could be private companies issuing those certificates. So if they operated a bridge or subordinate certificate authority, under our model, yes, those would be totally acceptable, provided - they would have to follow our certificate policy, obviously.
DR. STEINDEL: Yes, and that is actually a satisfactory answer, too, because we have heard from I think it was SAFE(?), which is a pharmaceutical organization that is planning a digital certificate. Right now, it is geared towards clinical drug trials, and, obviously, this is something that might involve controlled substances and it would be good if that cert could be used in the DEA situation as well.
MR. MAPES: Right. Provided they followed the certificate policy.
DR. STEINDEL: That would - thank you. That was good.
The next - this gets a little bit to Jeff's question concerning non-repudiation, and when you talk about PKI and you are talking about things like non-repudiation, you are starting to talk about a packaged message that has been encrypted with a private key and then decrypted with a public key. It is usually signed with an electronic signature and a hash is applied to it that indicates non-repudiation. Is that total package what you are looking for or are you just - and in your answer, you seem to indicate that you would accept components of the package, which would not be a strict PKI.
MR. MAPES: No, it's - those are all parts of an electronic prescription. When I was talking about the non-repudiation, we - that is a part of the system, but it is obviously not a part you could take out from the rest of the system and do that separately. The system you described is the PKI system that we are envisioning.
DR. STEINDEL: That is what you are envisioning, the total - because what we have heard is there is a problem in the total electronic-prescribing process with a true PKI system because in the electronic-prescribing world there are different standards that are being used, and you indicated your solution should be standard neutral, but, for instance, we may be in a situation where our prescriber would be using one version of a standard and hasn't had a chance to upgrade, and the pharmacy is using another version of the standard and a middle person would -
MR. BLAIR: Steve, could I just ask - be a little bit more specific, because I am not sure that he understands what - that you are talking about the message format standard, for example.
DR. STEINDEL: Oh, like, for instance, NCPDP script. There's multiple versions of NCPDP script. We may be working with a provider that is using version two and we may be using with a dispenser that is accepting messages in a later version, and there may be a need to translate between version two and the later version, and a lot of times, there is a middle vendor -
MR. MAPES: Right, and -
DR. STEINDEL: - and they have to open the message which then destroys the non-repudiation and destroys the PKI system. How do you envision that working in your system?
MR. MAPES: We have discussed with some of the same vendors that probably you have discussed with that same situation and we are looking at the situation to see where those vendors could fit in. So if the prescription did not go directly from the prescriber to the pharmacy but went to one of these third parties that would then take it, open it and determine what standard it was using and what needed to be for the recipient and then translate it into that and send it off, we are taking that into consideration and trying to see if we can account for that, adjust for that in the situation, because we understand the traditional PKI and how we have to take that and adapt that to the real world of electronic prescribing. So that is one of those issues that we are trying to take a look at and resolve.
DR. STEINDEL: And one last question, Simon.
How extensively are you going to be looking at the overhead of going to a PKI system? We have heard multiple different levels of actual overhead in terms of message sizes, the time it takes to translate the message, et cetera. Are you looking at that in your pilots in any great depth?
MR. MAPES: No, I don't believe we are looking at that in the pilots, because in the pilot that we currently have going, it is all within the same organization, but that is an issue we can take a look at -
DR. STEINDEL: Yes, because, I mean, some people have said that the overhead of a PKI system could be as much as 50 times what it is in a non-PKI system; and on the other side of it we have heard, you know, relatively low like one - you know, two to three times. So -
MR. MAPES: Right.
DR. STEINDEL: - that is an issue that is still up in the air.
MR. MAPES: Right, and -
DR. STEINDEL: And when you are talking about how many billions of prescriptions a year, that - if we are talking 50 times, that could be a big problem.
MR. MAPES: Right.
DR. STEINDEL: Thank you.
DR. COHN: Yes, and before we give it over to Harry, I just have one clarification I need to make sure I understand, because it is not really referenced anywhere in your overheads or anything else I have actually have heard from DEA previously. The focus of all of this is really on Part II – Schedule II medications and - which I think I heard you say unambiguously, but then explain to me again what the proposal is for III, IV and V. Is it to be determined? Is it something else?
MR. MAPES: No. We are developing a system that can be used for all controlled substances.
DR. COHN: And everything else.
MR. MAPES: Right. At the discretion of the holder of the digital certificate, the prescriber, in this case.
Because of the requirements for Schedule II prescriptions, because Schedule II's are much more abusable than Schedule III, IV and V and that is why they are in Schedule II. We have to have a tighter control over Schedule II's. Schedule II's cannot be, in any way - with one very minor exception - called in from the prescriber to the pharmacy currently. They have to be written. So Schedule II's would have to use a system like the EPCS system. Schedule III through V's currently can be called in, and if people wanted to continue to call them in, that's fine. This is - we are developing a system to allow for that - for electronic transmission - if they wanted to use that. It is not a requirement that they use it, just an allowance that if they want to.
So Schedule II's, if they are sent electronically, would have to use this system. Schedule III, IV and V's may not have to use this system. There are other systems that they are using.
DR. COHN: Okay. Or other approaches for -
MR. MAPES: Right.
DR. COHN: - authentication and non-repudiation.
MR. MAPES: Yes.
DR. COHN: Okay. And would that be - was there a proposal being made on how those were going to be handled in your vision or is that silent, at this point?
MR. MAPES: Well, the requirements will be in the - when the rule - the proposed rule making is out, it will set out requirements for controlled substances, and if a system meets those requirements, then they could use it. I know that is really -
DR. COHN: Okay.
MR. MAPES: - not enough of an answer.
DR. COHN: Yes. No - let me just try to ask it again, because I feel like I am almost understanding you, and I am very clear about what it is you are proposing for Schedule II. I mean, I - practicing physicians, I'm well aware of when I have to pull out my triplicates and all of this stuff, but - so I was just trying to figure out what exactly you were proposing for III, IV and V and whether there was a proposal or whether it was really a lack of a proposal, and I think what I am hearing from you is that you have a well-defined proposal for Schedule II, and for Schedule III it is likely that whatever it was you were - I mean, you really weren't proposing a solution for that in terms of appropriate level of authentication and non-repudiation.
MR. MAPES: We are proposing this for all controlled substances.
DR. COHN: You are? Okay.
MR. MAPES: But there may be other solutions that can be used for Schedule III, IV and V, because of the differences.
DR. COHN: Okay. Okay. Harry - I mean, thank you. I appreciate -
MR. MAPES: That's fine.
MR. REYNOLDS: Steve asked a number of my questions, but I'd like to play off of some of those a little more, and I'll just play off of what Simon said. You mentioned that it is only for two, but you feel comfortable that could be used for other -
MR. MAPES: Yes.
MR. REYNOLDS: – for the other schedules.
MR. MAPES: Yes.
MR. REYNOLDS: And I know we are not committing that it couldn't spill over in later legislation or anything else.
The other thing, back to what Steve was talking about also, it can go through one vendor or it can go through multiple vendors - you look at this flow from a physician to their practice-management system to a vendor to a switch to a - so there may be multiple stops along the way, not just one singular -
MR. MAPES: There could be multiple stops, yes, and we have to better define those stops and what is allowed and what can happen at those stops to be sure that we still have the integrity of the message.
MR. REYNOLDS: And as we heard the varying testimony, that is where the rub becomes when you get into PKI as you deal with it.
So I hear system sometimes and I hear standard sometimes. So are you recommending standards and then certain systems would have to meet those standards, is that correct?
MR. MAPES: Yes, our regulations will develop standards. Our PKI will be an infrastructure that we are developing that will meet those standards. So our regulations will be the standards for - and, again, technology neutral – but will be the standards that have to be met in order to electronically prescribe controlled substances.
MR. REYNOLDS: Technology neutral, but not process neutral.
MR. MAPES: Correct.
MR. REYNOLDS: Right. Okay. Thank you.
DR. COHN: Okay. Judy.
DR. WARREN: My question came early on, just because I have not heard this or anything, but you talked about two different PKI models. One of them was hierarchical and one was bridge. Did I understand that right?
MR. MAPES: Yes.
DR. WARREN: Can you just tell me a little bit about which ones - I don't understand those two models. So just a very brief –
MR. MAPES: Okay. Here we go. We'll try this. The hierarchical model would be the DEA certificate authority would be the top and every other certificate authority would be subordinate to the DEA certificate authority. So they would be underneath and subordinate to and follow our rules, our certificate policy.
The bridge certificate authority, the other certificate authorities, rather than being underneath and subordinate to, they may have several different purposes for the other certificate authorities, so while they would follow our policy when they are doing transactions involving prescriptions, they may do other transactions involving other things and would use someone else's certificate policy for those transactions. So they can be used for more than one purpose.
DR. WARREN: Okay. And then – so the bridging is there is no one that is really in charge of issuing the PKI - or not - that is the wrong word, but no one in charge of setting the policy. You would agree to use each other's -
MR. MAPES: Well, no, they would have to use our certificate policy in order to issue digital certificates in our system.
DR. WARREN: Okay. That is what I was missing. Thank you.
DR. COHN: Stan.
DR. HUFF: So my understanding of PKI and basically all of the non-repudiation issues is that it is all relative, in some sense. I mean, at some degree of sophistication, there is a probability, even with PKI, that somebody could successfully argue that it could be broken or it could be - and we - I mean, we are talking about things that are so - probabilities that are so great that it couldn't be broken, that any reasonable person would say, no, it wasn't and they would convict.
But I am wondering, then - I mean, it must have been your judgment that - you know - the other kinds of closed-system requirements that people have talked about, you know, if you had authentication using tokens or - you know - basically, a log in, a password and a token of some kind for authentication and then could assure secure transmission of the prescription over a closed network, other things, it was your judgment that those things - that there was sufficient difference between the risk of repudiation to justify PKI versus the other less - slightly less or a lot less secure mechanisms.
MR. MAPES: Right. In looking at the different options that are available, it looks like PKI is the one that provides - and, as you said, there is no absolute. There is - you know - to a mathematical certainty that the likelihood of them successfully repudiating a transaction would be very minimal. In others, that likelihood increases a little bit. So we have to look at them and say what would be the best for handling these controlled substances and how much risk is acceptable, and so, in the overall process, we determined that PKI is the best that is currently available. Now, that doesn't mean it will always be, that there will be other technologies out there that will also work at some point in time.
DR. HUFF: And I guess the - sort of the heart of the question is it is always sort of a cost-benefit question, and do you have an - how many cases actually come to trial where this is an issue, where - or how many cases, how many people a year are convicted of this kind of fraud?
MR. MAPES: I don't know what those numbers are. I could say that the numbers are a very small percentage of the prescribers of controlled substances, much less than one percent of the prescribers of controlled substances. So - but I don't really know what those numbers are.
DR. HUFF: And - I mean, you must have done some modeling to think, you know, of the cases that are tried when - you know - when would this non-repudiation be an issue versus other issues of evidence and other things, and do you have any idea? I mean, if we said - did you do even modeling to say if we do this level of security, then we think we might lose this many cases and if we did this level, that would make - you know - a difference in five cases or 100 cases or 1,000 cases a year, based on which level you did?
MR. MAPES: No, we didn't look at the differences, because the non-repudiation is one aspect of PKI and we didn't look at that in terms of the number of cases that we might win or lose over a period of time. That just wasn't a comparison that was made.
DR. HUFF: I guess along the same lines, in your Slide 33, where you did costs and benefits, as I understand it, one set of costs are the current costs using current paper system and other capabilities, and then you have the other benefits where we end up with cost savings of $24.8 billion a year or $24.8 billion over 10 years. I'm not - but, anyway, a lot of money. Do you know how much of the savings are due to use of the electronic system in general versus an electronic system that uses PKI versus an electronic system that used some lesser degree of validation and non-repudiation?
MR. MAPES: No, I don't. I don't know the difference in that -
DR. HUFF: Don't know -
MR. MAPES: That is an issue we could look at in more detail and get back to you in writing on that.
DR. COHN: I have a question, and I think Harry has a question and then Jeff has a question, and maybe we'll begin to -
DR. HUFF: Well, I guess I - I would just -
DR. COHN: Oh, you have another question. Okay. I'm sorry.
DR. HUFF: I guess it is just sort of - it would have seemed to me that the difference in your conviction rate would have been the ultimate justification for the increased cost between simpler methods and PKI methods, and so I am surprised that that analysis hasn't been done.
The factor that we were looking at is the level of control of the controlled substances, not of the number of people who had been convicted for violating the Controlled Substances Act. So we are looking at the level of control that it provides.
Well, I think it is the same question, though. I mean, you know, I am part of a medical provider group, and based on, you know, just regular kinds of key passwords, you know, we have successfully fired and maintained in court when those things were contested that people looked at records they shouldn't have looked at, and so, you know, for all of our normal business functions, which include things probably as important as - you know - controlled substances, we have been able to convict people with much lesser levels of security than are being proposed here, and so I am just trying to understand the justification for the increased cost when, you know, at least in my experience, much lesser levels of security have been sufficient for us to conduct our business with and, you know, up to and including convictions and other kinds of security breaches and other things that we convict people of.
MR. MAPES: Okay. And I understand your concern about the cost of that and the difference.
I would say that, in the paper world, when we are looking at a prescription for a Schedule II substance, the pharmacist has to take that paper prescription and look at it and make a decision based on what they have in front of them. So the pharmacist looks at it and they know that this doctor normally writes for a certain drug, which would also be available in the electronic world. They look at it and say, yes, this doctor always uses blue paper. They usually sign their name this way and all those kind of things that aren't available in the electronic world. So this is a way to try to make the paper and the electronic similar, so that the pharmacist can rely on that as having been signed by that physician, approved by that physician, not signed by or approved, because they don't have a physical signature, by an office staff member or someone else other than the physician.
DR. HUFF: I guess in that particular case, we heard a lot of testimony that even though those things are theoretically true in practice, the pharmacist rarely knows actually this physician's number or prescription pad or any of those other things.
MR. MAPES: Okay. Well, it depends on which pharmacist -
DR. HUFF: And that is why I was wondering - I mean, there certainly could be evidence that - those things, but I'm surprised that there isn't science that supports, so that you could say, this is the real difference in risk that we are taking between these two different approaches, and this is the cost benefit of that.
MR. MAPES: I can look more closely at the cost analysis that was completed - ee had a contractor do the cost analysis for us - and look at it and see what it says on those issues.
DR. HUFF: Thank you.
DR. COHN: Now, I have a question, Harry, Jeff does. Steve, do you have a -
DR. STEINDEL: I have a comment on what was just -
DR. COHN: Okay. Please, if it's a follow on, please.
DR. STEINDEL: - just discussed.
I think what Stan is asking is let's say there are N - in the world that we are dealing with, it would be fraudulent prescriptions. In the world that you are probably dealing with, it would be illegal prescriptions written. Let's say there are N of those, and we choose to use a PKI system, and, as was pointed out, the PKI system could be spoofed a very small percentage of the time, but could be spoofed. Let's say we could get 99.99 percent of those fraudulent prescriptions using the PKI system.
MR. MAPES: Um-hum.
DR. STEINDEL: If we chose to use a lesser system and we got 99.9 percent of the fraudulent prescriptions, is that other one-hundredth of a percent worth introducing a PKI system? And I think that is the kind of number that Stan is asking about.
MR. MAPES: Okay. And that is exactly the kind of input we have to have when we are making the decision in the process of rule making, that what is the difference? Is this difference worth it? Where shall we go that direction? And so that is the kind of input that we are looking for.
DR. COHN: Yes, and I would say certainly save those thoughts.
Okay. Harry, I think you have an issue on the -
MR. REYNOLDS: Yes.
DR. COHN: - a question on the same issue, and then we'll move to a couple of other questions -
MR. REYNOLDS: Playing off of Stan's comment especially.
When you think of PKI with the public and private key, those can very easily be embedded into a system to where you are basically verifying that it came from some computer, went to the other computer and both sides of that transmission knew the key.
Whereas, with passwords and other things that you may have people enter each time, you may be able to capture each time, whether it's - tokens change regularly.
So as you think about PKI, it has tended to be a point-to-point protection, not necessarily a singular body that has to do something every time, because a password - I have to enter my password or I have to enter my token number, which changes regularly, versus my PKI - my public key and private keys don't change, and so when you think about - so we are taking a point-to-point capability, and, now, we are moving it into where we have individuals out there.
So one of the key things that we all rely on - at least, what we have heard - is that the doctor signed it. In this case, the computer can sign it from that doctor's office, and that doctor may, in fact, never have to be involved, using just PKI. If you think about it, and I am just putting out a premise. I am not -
MR. MAPES: Well, that's why -
MR. REYNOLDS: So I think those are one of the things that, as you think about what authentication is and what goes on in a doctor's office and the closed systems and the other things that were at least brought up, that whole thing of point to point, but then once you step into the real people, we heard that some doctors have pads that they sign a lot of them, but at least they signed it and they took responsibility. Whereas, my - that PKI is system to system, and you've got fixed numbers. You've got fixed numbers on both sides, and so it is just something to add into your equation.
MR. MAPES: But in the design of our system, the digital certificate would probably reside on a smartcard, a token of some kind, and use a biometric to unlock that to use that, so that it could be used in multiple locations. It wouldn't be just a single location that the doctor could prescribe from. He could prescribe from multiple locations; and with the biometric, that would tie the prescriber to the digital certificate to the transaction.
MR. REYNOLDS: And the multiple locations would all require the smartcard reader. So -
MR. MAPES: Yes.
MR. REYNOLDS: So updating a prescription from home or anything else, you would have to have a similar device, he or she would have to have a similar device at home to be able to do that Schedule II in the middle of the night.
MR. MAPES: Yes, they would.
MR. REYNOLDS: Okay. Fine.
DR. COHN: Michael, thank you for answering all our tough questions. We do appreciate it.
I actually had a question that - I have two questions, and one of them sort of, interestingly enough, begins a transition along the lines Harry was asking. I mean, the subcommittee has been talking almost exclusively about PKI up ‘til now, and I know Jeff earlier sort of talked about this - you know - what pieces really make for all of this working.
Now, I think we would all observe that PKI probably is only as strong as whatever that authentication is going in, and Harry began to ask about that. I mean, I think we are all aware that PKI, you know, if it is your computer and it's turned on, anybody, potentially, could use it, and PKI would just authenticate that it goes from that computer to another one. So we really do get back to that issue of biometrics or smartcard or whatever it is that authenticates that Dr. Simon Cohn is actually writing that prescription, and, then, from there, it is being non-repudiated as it goes through, and I think that's what I saw as you were talking in terms of your proposal.
Now, but you were mentioning here - and let me just sort of ask this question: It appears that you are asking, or at least proposing, some sort of biometrics to be the thing that sort of unlocks and authorizes the whole PKI to work, and I don't see it being much more specific than that, but what is your sort of vision about all this? Because I think the strength of the whole solution sort of rests on its weakest link in some ways, and I - certainly, I have heard that - we have not heard testimony here specifically about it - that a lot of biometrics is - at least in clinical environments - is probably not quite ready for prime time, and, certainly, that is what I have heard as I have talked to people about it.
I guess I would also ask the same question about your CSOS implementation and are you going to be having biometrics for pharmacists ordering up medications, which appears to me to be a much greater risk. If I am ordering up 10 box loads of a controlled drug, I would really want to make sure that the pharmacist was who they said they were before they - you know - ordered up 1,000 or 2,000 OxyContin or something like that, but help me with this.
MR. MAPES: Okay. First of all, in the CSOS system, no, we are not requiring biometrics, and you have to look at the electronic - in this case, CSOS is part of a larger system of controls. In the CSOS world, the only ones with digital certificates will be the registrant, the owner of the pharmacy or someone who they have given authority to order controlled substances to, and, again, the digital certificates in that situation will be identity and credentialing. They will be tied to a specific DEA registration - in this case, the registration of that specific pharmacy. So when the pharmacist orders controlled substances from the wholesaler, they will - included in the information in the digital certificate will be the DEA registration number, the schedules authorized and the address of that pharmacy, so that the only place those controlled substances could be sent would be sent to that pharmacy.
And suppliers also, as part of the control mechanisms, have to report to DEA any suspicious or unusual transactions from a specific pharmacy. So if the pharmacy had an ordering pattern where they ordered routinely two bottles of something - a controlled substance - every week and all of a sudden they went up to 20 bottles, that would probably trigger that suspicious or unusual purchase so that the distributor would then let us know about that so we could take a look at it.
So what I am saying here is that the CSOS system, the PKI system for ordering is part of a larger system of controls that we have, so that we don't need the biometric for that, and the number of people that have those certificates will be much smaller.
Now, the biometrics as a whole, it is a technology that is maturing. We have seen demonstrations of several new types of biometric readers and that kind of thing, and that is probably one of the reasons that we want to further discuss the issue.
We know that biometrics is a key, and, as you say, it could be the weakest point with biometrics. I don't think it would be, but as the biometrics industry itself is maturing and the costs come down, then we can look at the cost benefit of using biometrics as opposed to not using it.
So we understand that some - in the past, some are expensive, large and difficult to use and those are coming down in price and in their reliability. So by the time this is out, two years down the road or a year, whatever it is, what is going to be available, I don't know, but we are going to work on setting standards rather than, again, any specific biometric piece of hardware.
DR. COHN: Well, Mike, thank you very much for this response. I guess I am - you know, I am not a pharmacist. I am a physician, but I found it sort of odd, and I am just going to have to think about it and will probably ask others who are testifying later today to comment.
I just - in some ways, it appears to be that you are - you know, if we are talking about distribution center and mom-and-pop stores, you are sort of not guarding the distribution center with the same rigor that you are guarding the mom-and-pop stores, but that is just - I would have to hear others think about this one. I just am sort of surprised about your analysis about the risk of pharmacies versus physicians prescribing, but, as I said, I mean, I think you are certainly allowed to have that perspective, and I would just like to get additional input on that.
MR. MAPES: One additional comment on that and that is for all Schedule II's and Schedule III narcotics that a distributor sends to a pharmacy, they report each and every one of those transactions to DEA, so that in - usually within a month's time frame, we know about all those transactions, look at them and determine if some transactions appear to be out of the norm. So, again, the CSOS is just part of a larger control mechanism for those drugs.
DR. COHN: Okay. Well, now, my final question on this one is just - I think at the end - and I actually really appreciated your last overhead, which sort of talked about this issue of the Part D pilot, and certain conversations we have all been having, you know, and, obviously, part of our role is to advise CMS on really what ought to be piloted for 2006 and maybe even a little beyond.
From your perspective, what do you think would be the appropriate role of those pilots to potentially - I mean, now, once again, obviously, you may just go forward with rule making, which may render Part D pilot sort of moot on this, but assuming that this could contribute some to your decision making and thinking, what are your thoughts about how the Part D pilot might be useful in terms of helping mature your thinking around all of this?
MR. MAPES: I think the Part D pilot would be useful, because it could provide us with some real-world examples of systems that worked well, systems that need changes, systems that didn't work well, and provide some more discussions with industry, with the pharmaceutical industry, with the doctors, with everybody involved, the pharmacists, so that we can get a better grasp on what will and won't work in those situations.
DR. COHN: Thank you.
Steve, is this a followup on this one for -
DR. STEINDEL: Yes, a followup on biometrics.
DR. COHN: Okay. Oh, okay.
DR. STEINDEL: Yes, when you are going to be asking about comments for biometrics, are you going to specifically ask for comments concerning the clinical environment and the use and success in that environment?
Because, first of all, biometrics, just in the general environment, as you point out, is improving in its reliability and its success rate, but the clinical environment, with respect to biometrics, is still a very dirty environment. You know, physicians take off gloves. They leave particles from the gloves on fingerprints, reduces the reliability there. If they are working in operating theaters, you have the same glove problem. You also have problems if you use - you know - just facial features, because they might be masked or they might be wearing a hood. So there is a lot of reliability problems that are different in the clinical environment than they are in just the regular world, and so I hope when you are asking for comments that you specifically ask for experiences within the clinical environment as well.
MR. MAPES: Absolutely. We recently had a demonstration by a company that is in the biometrics and their emphasis is biometrics in the clinical environment, and they told us about great successes that they have had. So we would want to look at the success that they have had with biometrics, the error rate that they found and those kind of things to see how good it can work in the real-world practice settings.
DR. STEINDEL: Yes, and we do have a surgeon present. I'm sure he can validate this. The reliability factor that he probably wants in the operating room from a biometrics reader is 110 percent.
MR. MAPES: Yes.
DR. STEINDEL: (Laughter. Twenty, he says. (Laughter).
DR. COHN: Okay. Other questions or comments?
Jeff, do you want to - get to a microphone.
MR. BLAIR: Getting back to the question that I had asked earlier, which was the protection of data integrity, is there any consideration that you have given to how secure the network might be? Is there any assumptions that you had as to whether or not the prescription is over the internet or a virtual private network or secure network, and if you are thinking of a secure network, you know, what assumptions did you have about what makes it secure or what standards did you envision in terms of what is secure?
MR. MAPES: Okay. Again, ours does not deal with the transmission requirements, but when we're looking at our system, we were making the assumption that it would be over the internet rather than over a VPN, so that it would be the most open, and if the standards work for the most open system, then, obviously, they will work in a more closed, more secured system.
MR. BLAIR: Well, if that is the case, and if the prescription is over a network that is, to some degree, secure, does that effect, in any way, your data integrity requirements?
MR. MAPES: No, we still have to have the requirement that we can demonstrate that there wasn't a change to the data in transmission, although we are not saying what the transmission requirements are.
It may be, as we craft the regulations, that there can be some allowance for that. Whether it is a closed or open system, I don't know, but, right now, we are just taking the regulations and assuming that it is the most open transmission system, so that they would work.
DR. COHN: Well, Michael, we want to thank you, and I really appreciate your openness in willing to have a frank discussion about all this stuff.
As you know, we are sort of really in the midst of trying to offer the best advice we can to the Secretary. So we really want to thank you. I suspect this will be not our last conversation about all of this, and, obviously, we'll be hearing from the VA about their pilot later on today as well as, I'm sure, having conversations about a number of the issues you brought up as we go along with the rest of the testimony.
So, really, thank you for some really great and for useful information.
MR. MAPES: Thank you for your time.
DR. COHN: Okay. And I think we move from here to a CMS update and Karen.
Yes, and we are pleased to have Karen Trudel and Clay Ackerly present the update.
Clay, as I understand, you are one of the Special Assistants to the Administrator.
MR. ACKERLY: Yes.
DR. COHN: So thank you for joining us.
MR. ACKERLY: And I just wanted to say thank you to your all's work so far. It has been fantastic to have such high quality - I know that Dr. McLelland(?) and the Secretary and HHS broadly a), you know, we rely on your expertise and it has been extraordinarily helpful to have, and, you know, makes us, you know, more confident in how we move forward with this important policy decision. So thank you for all the hard work and it is much appreciated.
MS. TRUDEL: Morning.
A number of you have already made remarks about the fact that I obviously have undergone an extreme makeover in terms of my presentation skills. (Laughter).
Want to talk a little bit today about the e-prescribing process under Part D, what we are doing in terms of the regulation, what we are doing in terms of some of the discussions about pilots, and so I would like to just talk a little bit about the timing and remind you of what we are looking at here.
We are still targeting publication of an NPRM for e-prescribing this month, and we think we have workdays left in the month that we could actually manage that. We are very, very close, and the next target after that would be a final rule, which would need to be published by October of 2005 in order to meet our ultimate target, which is to implement foundation standards when the Part D benefit becomes live in January of 2006.
I wanted to provide a little bit of feedback on what I have heard in terms of the - what I am hearing about the recommendation letter and the recommendations. I have heard very positive feedback. What I have heard was that the recommendations were very thoughtful. They were balanced and comprehensive, and, of course, very timely, and I think that from two perspectives.
One is I have heard a great deal of positive feedback by a number of different folks in industry who felt that they really had an extraordinary amount of ability to make their points in time for them to be heard and that the subcommittee members and the committee members were very open and receptive to a number of different points of view and really tried to balance them all out.
From an internal perspective, with respect to myself and my staff, as drafters of the regulation and the folks that we are briefing and trying to inform through the clearance process, I think the fact that we have gone through this hearing process gave us an enormous leg up, that we had received a very intensive briefing. It made it a lot easier for us to develop issue papers and briefings. We just had an extraordinary wealth of material to draw from, and, for that, I thank you.
I would also like to talk about - to the extent that I can - what is in the NPRM, and there are limits to how much I can say, because we are going through the clearance process, but one of the things that we have done is to describe the NCVHS process and the stakeholders. That adds to the credibility of our recommendations. It gives a very good sense that we have really, really done our homework here.
We summarized the NCVHS recommendations in the proposed rule, including some of the ones that we are not proposing at this point. So we are trying to give a total picture as to what we are starting with and where we expect e-prescribing to end up.
We also explain our incremental strategy, the fact that we do want to start out with foundation standards. We'll lay other standards over the top, as a result of the pilots, and that, ultimately, we are talking about a successful integration with electronic health records, in general.
I think that what we are proposing in the regulation will not be a surprise to any of you. We are talking about proposing foundation standards. Suffice it to say that they are very similar to the ones that the NCVHS recommended.
We also take an opportunity to try to explain a little bit better the concept of adequate industry experience as we heard it. So we have put out some criteria that we think we can use as good tools to measure adequate industry experience.
One of the things that we are doing and that you will see when the regulation is published is that there are many places where we specifically solicit comments on particular issues that we really, really want to hear feedback on, and the notion of adequate industry experience, because it is so basic to the concept of the foundation standards, is one of the places where we are doing that.
There is also a fairly extensive discussion of state preemption raising a number of the issues that we have heard in the hearings, and we will be specifically, again, soliciting information and comments on that notion.
Also, we will discuss Stark and anti-kickback, but we will be making a statement that those both will be addressed in separate regulations, so you should not expect to see any specific Stark and anti-kickback proposals in this NPRM.
The next thing I would like to talk about a little bit is pilots. We know that the law says we need to announce initial standards for pilot testing by September of 2005 and that the pilots need to be operational in 2006.
We are still working right now on the structure of the pilots. One of the things that we are using is, obviously, the NCVHS recommendations. Margret was able to distill a matrix or a checklist almost of things that people suggested in the course of the hearings be pilot tested, and so we can use that as something that we can use as a building block to develop the pilots.
We also have done our own environmental scan of existing e-prescribing programs, and we are still in the process of evaluating those results, but those, also, will definitely inform the structure and the nature of the pilots, and I think you should look to see an announcement about pilots, at least at a very high level, probably within the next month.
And I would like to remind you about the subsequent milestones that we are looking at. After the pilot tests are finished, a report to Congress, no later than April of 2007, and proposed and final rule, no later than April of 2009, and, again, if previous notions hold true, we will be pressed to deliver those things well in advance of those milestones, but that is basically where we stand right now.
Again, I thank you for all of the support. It has made our jobs a lot easier.
And, Clay, do you have anything you want to add?
MR. ACKERLY: No, just, again, to say thank you for moving so quickly. You know, as you said the precedent has been set that we are trying to move ahead of these deadlines, given what e-prescribing can mean to the quality and the efficiency of the Part D benefit in prescribing for seniors and what it can mean for the entire healthcare system. So this is really important and thanks again.
MS. TRUDEL: Any questions?
DR. COHN: I know Jeff has a question and Steve has a question or a comment.
I just want to, first of all, thank you for the compliment. I mean, we - obviously, we worked hard, but I think we are very proud of the work that we have done so far and, obviously, look forward to continue the close collaboration. So thank you.
Jeff, you have a comment, and then Steve.
MR. BLAIR: Yes. Clearly, the schedule to move forward to get ready for the pilot tests is limiting a lot of things that we might like to do. Right now, NCVHS is working on trying to come up with recommendations for the e-signature portion of e-prescribing.
Could you maybe give us some feeling for either whether that will eventually be included in the NPRM or will it be handled separately or how will this fold into - or is that not known yet?
MS. TRUDEL: The quick answer is there's a lot about the pilots that we don't know yet, but just kind of doing the math in my head, I think we are talking about the next set of standards coming from the subcommittee in March, and I think if there are clear paths that we might want to test, even if they may be multiple paths that we might want to test, you know, differentially, it would seem to me that there would be adequate time to work them into the pilots.
The other thing is that from my perspective, at least, I don't expect that every pilot is going to test every single potential standard. I think what we need to do is to have enough experience that we can put things together, but I would think it would be very, very difficult for any pilot to get up and running if it were testing every potential possible standard that we could be considering, and so there's - I think we have some latitude there in determining how exactly we distribute the testing load.
DR. COHN: Okay. Steve.
DR. STEINDEL: Karen, I won't comment on the extreme makeover.
MS. TRUDEL: Thank you.
DR. STEINDEL: But I do have a question. You mentioned that - when you were talking about the incremental steps, that is just kind of preamble material about where you are going -
MS. TRUDEL: Yes.
DR. STEINDEL: - because I am concerned about the implications with the electronic health record. You know, obviously, this is going to be a direction towards it, but I don't know if we know enough to say anything more except in preamble material.
MS. TRUDEL: And we don't, but what we need to do is to signal to the industry that the department recognizes that these things all have to come together in the final analysis.
DR. STEINDEL: Yes, I am very comfortable with that statement.
MS. TRUDEL: Yes. Exactly. That is the point.
DR. COHN: After our DEA conversation, this has been very – appears to be very quiet. (Laughter).
DR. STEINDEL: Can we ask what the iconology means?
(Laughter).
DR. COHN: I guess I would ask - obviously, we have just been talking and having conversations with the DEA. I presume that their participation would be potentially welcomed in pilots in 2006 if they felt it was important to test various approaches to areas that they are concerned about.
MS. TRUDEL: Oh, I think we are very open to discussions with our colleagues at the DEA.
DR. COHN: Okay. Good. Good.
Well, okay. Well, I think we're done. Thank you very much. We look forward to the NPRM. I presume we have 60 days to respond to it, once it hits the street.
MS. TRUDEL: Yes.
DR. COHN: Is that a reasonable assumption?
MS. TRUDEL: That is correct. Yes.
DR. COHN: And we'll look forward to seeing it. Thank you.
MS. TRUDEL: And, hopefully, we'll be back with another presentation in more detail very shortly.
DR. COHN: In February. Okay. Obviously, we appreciate the opportunity to provide meaningful input to it. So thank you.
MS. TRUDEL: Um-hum. Thanks.
DR. COHN: Bye-bye.
Now, we will take a 15-minute break, and then we will start off on our next session.
(Break)
Agenda Item: Overview of DEA/VA Pilot
DR. COHN: Okay. Our next session focuses on the Veterans Administration/Drug Enforcement Agency PKI pilot. We are pleased and delighted, actually, to have Robert Silverman from the VA coming to brief us about the pilot. So please. Welcome.
MR. SILVERMAN: Thank you. I really appreciate the opportunity to talk about the DEA PKI pilot.
To frame my involvement - Able to hear me there?
DR. COHN: Now we can hear.
MR. SILVERMAN: Okay.
DR. COHN: We're sorry, but these microphones are temperamental and you need to get close to them.
MR. SILVERMAN: Very good.
To frame my involvement, my background training is as a pharmacist and my day-to-day responsibilities are as a coordinator of CPRS, which is VA's electronic healthcare record.
In terms of this pilot, I have been Hines VA Hospital's site primary point of contact for about 2-1/2 years - to DEA, to the prescribers, to the various contractors we'll talk about. So that's the framework where I am coming from.
Today, I'll focus on five areas. Briefly, I'll get back on to e-prescribing in general at VA.
If I understand, not everybody here may or may not have had opportunity to see CPRS in action. I have some static slides to show what our daily routine of electronic prescribing is like. We'll talk about the pilot. I will go through some of the steps that our practitioners face to - what I would call - enroll in the pilot. So you can see step by step where does the information flow, and you'll also be able to get a sense of the security that is inherent in the process we use within VA, some static screen shots of DEA e-prescribing directly off of our system, both at Hines and off of one of the test databases, and then summarize our findings over the 2-1/2 years that the pilot has been operational.
First part to that is that e-prescribing is a day-to-day occurrence at any VA medical center. At Hines, the CPR system has been operational since late October 1998. So the idea of entering a prescription electronically, having it transmitted to the pharmacy, having it received and filled by the pharmacy - in some cases, before the patient can make the walk from clinic to pharmacy pickup - is very commonplace, and that is, I feel, an important background towards the changes in controlled and secure prescribing, such as the PKI pilot provides, because that is a level of security on top of an existing e-prescribing environment. It is not adding, oh, now, we have to prescribe electronically and enforce the security system to it. The electronic prescribing exists, and we are adding the security as another layer to it.
Prescriptions are transmitted whether they are controlled substances, legend prescription drugs, over-the-counter items, and at VA, effective about six or seven months ago, our medical-record system now also allows documentation of any over-the-counters that a patient might be taking from outside VA sources. So if we have a patient who is being treated in a primary-care clinic and is also receiving their opthalmologist care outside, we can document a complete profile, not just what is a VA pharmacy providing and dispensing.
So we have the compete history, allergy and adverse-reaction checks against both VA-prescribed and non-VA-provided medications, and through today's technologies, such as VPN, that is available routinely outside of the facility.
At Hines -
MR. BLAIR: Could I just ask a brief question?
MR. SILVERMAN: Sure.
MR. BLAIR: Because it is effecting my ability to absorb all of your other comments here.
When you are sending this to a pharmacy, is that a commercial or retail pharmacy or is that an in-house pharmacy?
MR. SILVERMAN: Everything I am talking about is in-house VA pharmacy. This is a closed system. I think that has incredible bearing on how the system functions, and, to some of the questions you were asking earlier about open transmission of the prescriptions, this is VA clinic to VA pharmacy.
Anyway, to finish on that point, remote can mean at university medical center, our affiliated hospital across the street, or it could be at home of the provider using secure VPN.
What I have here are just a couple of shots to frame what it is that the prescriber is seeing. See if that pointer works here.
This is our - cover sheet, a single-screen overview of patient care. Across the top, patient demographics, current activity, postings allowing access to allergy information, a current medication profile, our clinical reminders, which is our guideline support system, and even just from this cover sheet, you have access to what I call more detail than you ever want to know about a given prescription - who wrote for it, when it was prescribed, when it was signed, if it was written in - awaited an electronic signature for a little while, when it was filled, by what route it was filled. All that information is available readily in real time.
Across the bottom of our chart, we have these tabs, presumably designed to mimic the tabs of a paper hard chart, and so this is a screen shot of the medications tab, more detail of that same section you saw in our cover sheet, a given prescription with instructions, quantity, relevant dates.
It is not just a look-up system. It is an order entry or e-prescribing system. So the order builder takes care of the typical components that are going to be required. Let me see where the mouse is here. Drug name, dosage, route, schedule, whether it's a PR in order, and, in the case of a prescription, a day's supply, a quantity, refills, when allowable, method of pickup and the order to be sent.
So everything that I am showing here is what I have called the day-to-day prescribing. This is all without PKI. These prescriptions are transmitted VA clinic to VA pharmacy.
And then the method of transmission here is an electronic signature code. That is a - I don't really know all of the right security words to use for it, but that is a single or simple signature code like a password. It is not the systems access password, but same idea. It is a simple unidirectional code that isn't shared on two sides. It's a password.
And so what we are faced with for the DEA pilot with VA is - here is this regulation. We've got - regulation states Schedule II's may only be prescribed with authority of a written prescription, and so for everything you have seen, we've got an environment where over-the-counters, legend drugs and Schedules III through V are prescribed electronically, and one remaining pocket of prescriptions that must be written, whether you call it grey form or purple form or whatever color you perceive the VA prescription pad to be, ink-signed and delivered to the pharmacy by some method. That could be foot traffic by the provider or it could be foot traffic by the patient, but there is an inherent delay in that transmission because the prescription has to get there somehow, and so that is a notable pocket to an otherwise all-electronic prescribing environment.
And I'm sure that this slide is no surprise. It is the exact letter of the regulation that defines written prescription requirements for Schedule II.
I believe that a copy of this presentation is being made available for everybody on paper as we speak.
With the changes to our CPRS medical-record system that are a part of the pilot, the system is now smart enough to recognize that there is a possibility for PKI digital signature, and since it knows that there is a possibility, it is able to effectively block attempted entries of Schedule II medications without that digital signature. So the screen I am showing here is an attempt to write a morphine prescription without using smartcard and without using PKI signature for it, and the system responds, I'm sorry, but that may not be transmitted.
And so the first advantage that we achieved by participating in the pilot is that there is no longer an attempt to transmit these prescriptions. The prescribers around the room may be familiar with what drugs or what schedules found that that is not uniformly the case and a frequent question is, Is such-and-such drug Schedule II? or, more commonly, I entered Tylenol with Codeine and it didn't prompt me for my card. What's wrong? And I have to remind them that that is Schedule III and not subject to this.
So this was an early advantage, before we even get into PKI and secure signature, is that the system is now smart enough to block prescriptions appropriately that require that level of security.
I'll talk a little bit about the pilot itself. I call it an ongoing pilot. There was a formal review period that has ended. Gap analysis papers were written to define all of the issues identified during that time, but the system is still in use at Hines. We still are learning each week of new issues about PKI certificates, what happens when you renew those certificates, and, to the best of our ability, with the resources available, we try and continue to fix them, and, if not, document them. So any copies of the official gap-analysis paper at the close of the pilot won't necessarily include everything that we have learned to date within VA about how our system works, and the scope of the project was to demonstrate the application of digital signature in place of written signature when we are transmitting electronic prescriptions.
I have borrowed this from DEA's website and the middle part here.
During the PKI test period, DEA is exempting participating pharmacies. In this case, it is the Hines Veterans Hospital pharmacy specifically by street address that is exempted. The little grey box there is just my reminder, I think, that it is Chapter 1306 and not 1304, but - (laughter) - that is not relevant to this. It's - whatever the table is, there is a regulation that says and there is a waiver from DEA for our participation. So that is the specific method by which Hines is participating in a system where we do not have written signature on these prescriptions, and I have provided the reference for that site.
As the pilot began in October of 2002, we identified 50 physicians, based on a report from our prescribing system of who wrote the most Schedule II's. In order to get the highest potential volume of prescriptions transmitted, we wanted to find out who was most likely to prescribe those drugs anyway through normal course of their practice.
We have selected 50, and since then, we have had some attrition. New prescribers have asked to participate and prescribers identified in that 50 have asked to return to written prescription writing, and so, right now, we are at about two dozen, approaching 30, active physicians using the system, again, each day or each week.
Every time I have checked recently, there has not been a day to go by during the week without at least one PKI-enabled prescription transmitted.
What I wanted to do here is identify the different roles that have been involved in DEA's pilot with VA or VA's pilot with DEA. DEA is obviously a big part of it, and PEC, who is DEA's contractor, has been involved. I will describe some of the specific roles that PEC has performed and worked with us on that.
VA's Office of Information, that is our software and technology department, has had several roles in this. An office called Emerging Technologies, which is the housing area for PKI and the infrastructure of security things. There is an infrastructure group itself. That is our programming office that deals with things like passwords and system access, and then, obviously, the CPRS and pharmacy programs themselves have been modified to understand and accept digital prescribing.
VA is separated into VISN's. Essentially, these are regions. There are 21 regions, and each region has an information security officer. That person and each station's - again, in this case, just Hines right now - information security officer are involved in the process, CPR's coordinators, the role that I play, and then IRM - that is our Information Resources Management Department - has a role in the entire cycle of this, both from setting up work stations and setting up the central server.
One of the questions I heard earlier was there would have to be a card reader at each location where this is to be used, and that is exactly the case. Over the 2-1/2-year course of the pilot, we have gone from zero readers at the beginning to probably about 300 to 400 card readers available in our facility, and I am guessing about 60 of them have been enabled specifically for the software support necessary to utilize the DEA PKI functionality.
To get a little bit more specific about the goals, we wanted to create the infrastructure necessary to transmit a digitally-signed prescription. Again, that takes our kernel program - that is the medical records operating system, if you'll allow the analogy - the medical-record software itself, the pharmacy software, and it takes certificates.
I call it kind of for show-and-tell, but I have a total of seven smartcards here each of which has been a different stage in the pilot. Some of them are inactive now. Some of them were good long enough to find a single bug and then replaced and two of these I use on a day-to-day basis.
And we also wanted to compare existing electronic signature. What does VA do for every other prescription on the books to a PKI-enabled digital signature?
I would like to frame my idea of the continuum of signature methods. This does not come from a specific security background. These are loose terms that I use to describe the system frequently when I am trying to describe it for a prescriber that would like to participate.
At one end of the spectrum, you have the written signature of ink and paper. We have other systems of e-signature that are used in performing a captured signature. Think of the credit-card machine you would use at the store. In those cases, you are capturing an image of the person's hand movements. We have the electronic signature, the slide that I showed earlier, and then the digital signature or one example of that is PKI where a provider knows both an electronic code and has possession of a card to match the token of that code.
Somebody asked when I was providing this before where do ATM machines get into that level, and in terms of the amount of security, I think an ATM machine, although it is not a chip-based technology, is approximately equivalent to that highest level of the digital signature. You have possession of a card and knowledge of a number to that card. In other words, two parts necessary to execute the transaction, and that two part is going to become important when I go through the security process that is unique to VA's closed system.
As I know that the hearings today have already discussed, there are three parts that make up the security of a digital signature - the integrity of the prescription in transmission, the non-repudiation of the author and the authentication of the identity to that author - and the pilot system is able to address all three of them by identifying that the prescription is not altered when it is received by the pharmacy. The prescriber cannot deny that they are responsible for the signature that caused that transmission to take place, and that person is the only person who could have initiated that transmission of the prescription.
So what I'll go through is the process from a provider's interest in participation through to the transmission of a prescription.
Typically, in today's pilot environment, a provider will contact me and tell me that they have heard about the pilot and they would like to be issued a card so that they can digitally prescribe and - you know - they want to ditch their prescription pad.
So my first responsibility there is to contact PEC, and PEC locates the provider's DEA registration among a table they get from DEA weekly, and that table contains, I believe, every DEA registrant in DEA's system. So PEC is looking, do I have a match for the provider to validly identify that we have a name and a DEA number that match? And if they find that, they are currently transferring it to a small database of VA participants.
When they transmit that information, they are also confirming back to me that the record has been added, and so if I know the record has been added, I will provide the physician with an application or a registration form. This is a paper form at present.
The act of filling out that form verifies the identity of the prescriber. I am asked to check a photo ID, in fact, and make sure that I know that the person signing the form is the DEA number and the personal identity of the named signer, and I transmit that over to our VISN information security officer.
Their role in this process is that they have the only secure access to generate an enrollment code. So by validly identifying that I have a known person signing for this, the VISN security officer will return back to us an eight-digit enrollment code that is to be delivered securely to that provider. I try and stay out of that process, even during a pilot where a lot of things are dealt with hands on. I try and stay out of at least one of the loops to enforce the integrity of our system.
So I have - take Dr. Ferrer, for example. I have personally met with and identified that he is who he states he is. He has a photo ID that states who he is, and his DEA number is what he states it is, and, in return, he gets, independently, an enrollment number that is unique to him.
He can then go to a website and that website will deliver the electronic certificate to the smartcard, and that circuit is the first part of the security. Only he is able to get his certificate on his card, and that certificate contains essentially his DEA number.
For any of the process here, happy to address questions when we get to the end of that. Is there one currently?
DR. STEINDEL: Yes, I have a clarification question on the one - said resident physicians without individual DEA numbers also require pharmacy authorization. Could you explain what you mean by that?
MR. SILVERMAN: Right. Sure.
DR. STEINDEL: Seems like a weak link in the system.
MR. SILVERMAN: In the VA, a practitioner may have their own DEA registration or they may be prescribing under the authority of the facility. At a certain point during the process, they are not yet eligible for their state licensure, and, therefore, not eligible for their own DEA number. So we use a facility-specific number and a resident physician's specific suffix, AB 1234567-X 9876.
DR. FERRER: Under those circumstances, the resident physician is prescribing on behalf of the attending -
MR. SILVERMAN: On behalf of the attending and under the auspices of, essentially, the chief of staff. So you have two lines of authority that control that.
Make sure I go the correct direction on this. There we go.
So at the website, the provider will register for a certificate using that enrollment code, and that certificate is delivered directly to the smartcard. That is another one of the unique aspects of it.
Earlier, we were talking about PKI being an aspect of something that is on a computer. In this case, the certificate resides on the smartcard, so it travels with the physician and it also isn't left at the computer to be used by any subsequent users of that specific workstation.
Some of the other tasks that are in our current process are for the physician to select a PIN number to the card, and, in this case, that can be a PIN number or biometrics - we'll talk about that a little bit - and in the example of this particular, out of my seven cards, get the photograph printed on there, too.
I don't expect you to be able to read all the fine print on there.
This is an example of one of the things we have done for the pilot. During the transition from one brand of smartcard-specific vendor to another vendor, providers had to re-enroll, and so this is the level of detail - whether you consider that a lot of detail or a little detail - I was able to boil down to a single page - and that prints a little bit nicer on 8-1/2 by 11 - what it takes for a provider to get everything that they need onto the new card, and so that is ane example of what type of information we are giving our prescribers to independently be able to continue their use of the system.
And so after all of those steps have been completed - the request to participate, the entry of the physician's name into the database, the retrieval of the certificate - the last step is basically for me to acknowledge in the system that the provider has done all of that, and that is me flipping an electronic switch to say, okay, computer, it is now appropriate for you to accept a digital signature prescription from that given provider.
And so my opinion of what makes that a secure system is first of all that the certificate that they have obtained on the website matches their DEA number. The account that they use when they sign on to the electronic medical record system matches their DEA number, and so if they are able to sign the prescription, it is more than just a two-part circuit of completion. It is actually five parts. They knew their access code - basically, their user name and password - to sign onto the medical record. They knew their signature code, the old-style one. They possess the card. They possess the PIN number or whatever is - you know, whatever is used to unlock the card, and the certificate on that card has not yet been revoked. So all of those things are assured and guaranteed by a prescription that gets transmitted. If any of those break, the prescription just doesn't transmit in our system and it won't go through.
I'll quickly run through a second set of those slides about some of the things that might change if we were to scale this nationally among VA. Again, it is important to note that this is still a closed system within VA. These are not ideas of scaling nationally to private pharmacies and physician offices, but this is scaling from single VA to all VA's potentially using the system.
First of all, we wouldn't need to individually identify somebody asking to participate. All prescribers would have to be eligible by virtue of having a DEA registration.
Secondly, they would be able to obtain the registration form directly off of a website, not specifically that it is a DEA website, but it is some publicly-available website, and probably appropriate that they should still sign it in the presence of somebody who is validating their identity. I think it is useful to have one human factor in the issuance process.
I see a question there.
SPEAKER: Could that be a notary?
MR. SILVERMAN: Could it be a notary? I would say perfectly so. Within VA, our ISO's effectively act in that same role.
The application form would be transmitted to the local registration authority. That is LRA. That might still, within VA's case, be the regional information security officer. We still need to generate an enrollment number. I am not tied to the specific security of it being eight digits long. Seven or nine probably have their own validity themselves, but it is an enrollment number that is used, delivered back securely to the participant, and the participant would use that to get their digital certificates on the smartcard.
Another goal of this course is to consolidate this smartcard activity with other smartcard activities, and these are all things that VA has in mind with a project called the One VA Card - access to the grounds of the facility, access to the parking lot, access to the buildings, access to other things that PKI is used for, for example, secure email, in which a card should be large enough in terms of the virtual memory to hold certificate for DEA and certificates for secure signature and encryption of their email, and that is one of our goals is to continue the pilot and know that we have cards that are up to that task of having those three certificates on them and function correctly for all three purposes.
We would still have a step required for the electronic medical record to have - as I described it - have the switch turned on for a given prescriber. It is important that if you are not participating in this, there is no sense for the computer to run all of the checks necessary to see if you are going to give it a digital signature or if you are just not going to, and that goes back to the slide I showed. If you don't have the switch turned on, the computer will respond, I'm sorry. That is a Schedule II and you need to provide a written prescription.
And this is a duplicate of the same slide. I think whether or not we have some of the personal transmission, physicians being identified individually – it matches on the card, it matches in our electronic medical record and the provider has the smartcard and the token appropriate to unlock that.
So this time, these screen samples are what you would see if utilizing smartcard and prescribing morphine prescription. This is - it is off of a different system. I don't remember if I duplicated the prescription exactly, but I think it is the same prescription that I showed before. Morphine, 30 milligrams, twice daily. Same screen. You know, same entry process. Drug, dose, schedule, route. Same electronic signature codes processed to go. That is the simple password used for Schedule II, Schedule III through V's, legend drugs, and then if the system recognizes that there is a Schedule II in the batch, it will prompt for the smartcard's PIN number and use that to query the card and affix digital signature when appropriate.
The system responds back to the prescriber with a statement that the prescription is digitally signed, that is - some prescribers want to go back and see that it worked, and this differentiates digital signature from electronic signature. There is a certain comfort level - the provider that once they know it works, they stop checking this each time and they know that if the system asked for the PIN number, it worked fine.
This is a static screen shot of what the pharmacist will see on the reverse end. They will see two lines, Processing a Digitally-Signed Order and Digitally-Signed Order.
This is their indication that they do not need to wait for a paper copy to come through and they do not need to expect to file a paper copy in the record keeping. If these things appear, that is that the software has validated that there was a digital signature on the order and that the contents of the order now match what they were at the time it was signed. I don't know that I could really describe how it works internally, other than to know that there is a hash created, and if the hash that would be checked now matches what was created back then, the prescription has not been altered. So this tells you that that prescription is - it has integrity, compared to when it was written.
This is more for the take-home part of the handouts. I have tried to boil down the hardware installation to the simple steps necessary, so that we can, within our own hardware support staff, role out more computers and enable more physical workstations as rapidly as possible, and, essentially, it takes about six steps - six different pieces that get installed above and beyond our standard workstation to enable the DEA PKI functionality.
This one is, for your records, a copy of that provider's written application to participate in the project, and I perceive that, for the short term, something similar to this would still continue to be used, a written and personally-validated application to the DEA of, yes, I want to have an electronic copy of my DEA registration on a smartcard.
So what are the findings that we have had so far? First and foremost, it works. I have been told that that is a grand understatement by the practitioners actually using this. They love it. They love not having to carry their prescription pad with them. They love not having to figure out a way to transmit the prescription to the pharmacy, either walking it themselves or give it to the prescription (sic).
And it is not just the delivery that is received favorably. Electronic prescribing in our medical record ensures a complete prescription. You cannot transmit a prescription unless it has a quantity on there. You cannot transmit a prescription without a schedule or, effectively, a set of instructions, and so, whereas, you had the III through V's and non-controlled substances all being checked by the system, now, we have Schedule II's being checked by the same thing and you can't write out a half-complete prescription and try and transmit it. So you have that.
You end up with one-stop shopping for handling all prescriptions in the same manner, and there is an economy of scale to the pharmacy as well. There is reduced storage of the paper prescriptions necessary because you have the electronic copy. Our files are backed up through the regular routine backup of every other prescription file. You don't have to keep the boxes of - in this case, it would be the prescription stamped with the red letter C and all the things that are traditional to Schedule II controlled substances.
Some of the things that we have solved during the pilot, we have had a transition in smartcard type. Again, that's my pile of seven here. We completely changed vendors of smartcard and have successfully navigated through that transition and the issues that it raised.
We have had a change in the CA. There was a new sub-CA that came on board during the pilot and we had a successful transition through that where the CA's might be entities that you recognize. There was an EPC SCA, the e-prescribing for controlled substances certificate authority, and that has been superceded by a CA called the E-Commerce. It is essentially two computer systems performing the same role, but we have navigated through that transition.
We have had two changes in the software used to read the cards. Those have been navigated successfully, and one of the components that is used on our workstations is called the COM object. Effectively, that is the little bit of software that tells our medical-record system to look for a smartcard, and I think we have gone through 10, if not more, updates through that, as we find issues, and that is now stable since last September. We haven't had need to change or other changes from external sources on that particular piece of software, and we use one that was created in September ‘04.
We had issues that we faced where if I went to a clinic office and I activated a workstation it would work for that prescriber who was in that clinic on that day of the week, and we have now successfully made it so that it can work for anybody using that room.
We have worked through an issue called PIN caching, which goes back, a second time, to the topic of is PKI something that is a token present on a computer and there for the next person to access, and, in this case, the system we are using allows PIN caching. If you put in your PIN number once, it can save it for a specified period of time. We have gone on the level of what I'll call extreme security. We have lowered that to one minute. What that does for you is that if you are writing two or three prescriptions on the same patient, you can authenticate the card a single time and you don't have to authenticate, okay, here is the morphine for PR and Breakthrough. Here's the Fentanyl patch. Here's the other prescription. You don't have to enter a PIN code for each of those, but in the time it would take to get to a next patient, it will ask again. So the card and the authentication to the card are continually challenged.
And working through the process even forced the VA to reevaluate our own drug file in the computer system of what defines a Schedule II drug. We uncovered a need for clarification to that, and this project has helped us fix that up, so that Schedule II really defines Schedule II and not inappropriately defines narcotics. I heard one of the practitioners talking about the non-narcotic C2's, and we kind of got that in line as a result of the pilot.
We have had some experience testing biometrics. There's a particular vendor. I am not endorsing nor criticizing any specific vendor by this. These are just examples of pieces of equipment available in the industry.
We used one smartcard reader that is the precise MC 100 model. It's got a little glass chip that is a fingerprint reader in there, and there is something unique about me. I was the only person in a room of 20 people who had trouble getting a fingerprint to take on there, but since I was the site point of contact for this, that was enough to effectively put a halt to that. (Laughter).
We did some testing at the medical center, and we found that the longer a provider had been at the hospital, the better their chance was that they would get a good fingerprint take, and we wondered if - you know - enough hand washing over a career had something to do with it. (Laughter). Whatever it was, that particular model didn't work.
There's another example. I saw it at a VA conference, effectively the trade-show side of the conference, a brand name called Identex Biotouch(?). I am in no position to endorse it. All I know is that I walked up to the vendor demonstrating that model of fingerprint reader. First time, worked for me. So there is either something unique about me or there is something unique about that reader that in the year-and-a-half between the initial pilot and when I saw that, fingerprint readers have improved in technology. I think the latter is probably the case.
We've got some gotchas where the level of access to VA computing systems necessary to participate is a little bit higher than what Office of Cyber and Information Security would really like the everyday practitioner to have. It is a level called PowerUser, and that is a level of computer access that we are not really comfortable with handing out to all practitioners and all prescribers, but the current infrastructure requires it, and so it is a lesson learned and a lesson that can probably be solved between now and national -
And, right now, we are tied to a specific smartcard vendor. We have already learned this once, that if you change smartcards, you have to change a lot of the guts that work on the way through. We know what those are, because we have gone through it once, but if, for whatever reason, we were to move to a third smartcard vendor, we would have to move to a third iteration of all those other things. Those are just some examples of things we have learned about the pilot, that you can't deny it works right now, but it works because we have a fixed set of equipment and circumstances put together.
The security needs for a certificate that is used in a DEA prescribing are a little bit different than the needs of a VA email certificate. My email certificates can sit on my computer workstation in the office just fine, and when I want to sign and encrypt an email, it asks me for my PIN number and I put it in, and I can set it up so that if my card is there or not there, it still works. It is not a smartcard-dependent process.
The DEA pilot has been set up specifically to be a smartcard-dependent process, so that you carry the one copy of the certificate with you. You don't leave it on computers all around, and that is a situation where the software used to operate these systems is much more commonly designed. Its defaults are based on, I work at a desk in an office, and so we have to change some of those defaults away from standard to, I work in a clinic where I might be in Room A or Room B or Room C at any given time, and I want my card to work effectively in all three of them.
We tried a little bit with card-based log-on to the network. There might be some time savings there. I think the bigger savings is that it is easier to remember your PIN number to the card than it is to remember your password to the system, and the savings are probably more so from that than anything claiming to be a time savings of using the card to access the computer systems.
I am accused sometimes of living in an idealistic world. One possible future model - and this is Rob's words only - is an idea where a DEA registration website would be a place where you would renew your DEA registration, and if you had a smartcard reader capable of doing so, right when you are doing that, you could get your certificate at the same time. I don't think that is out of the bounds of possibility. It is just out of the scope of what we are dealing with right now, and a possible goal to aim for that DEA registration renewal and certificate provision are one and the same.
And I see a couple of copies of the handout. So you have my phone number and email for followup and questions after today's session.
That is the conclusion of what I have formally.
DR. COHN: Okay. Well, Robert, thank you very much for, I think, a very interesting session. I can see - I think, everybody has their hands up here and we'll sort of go around here.
I guess I just wanted to start out with just a question and just sort of a clarification from my view.
I noticed that you had been testing PKI with a smartcard, and I think what I heard from you was, I think, sort of a frank admission that biometrics are going to be extremely user-dependent, and, like many things in the world are, maybe not quite there yet - this realm, and I do remember - at least my understanding of Peter's testimony by the DEA was they appeared to be suggesting some sort of a combination of biometrics plus PKI. So I guess - am I right that I am sort of hearing from you that smartcard plus PKI appears to have been tested in the VA? I don't think you make any statement that the biometrics had really been tested or were ready to go.
MR. SILVERMAN: Sure. And I don't deny that having me be the particular person who had trouble with a fingerprint may have had an impact, but it had an impact nonetheless.
The software that we used at the beginning of the pilot was a program called Passage. It is an RSA security program, and RSA is one of the standards out there, and Passage had a setting for smartcard authentication that you could authenticate with your PIN number or you could authenticate with a biometric fingerprint or a combination of the two. It was intended for the pilot that we would actually test all three of those scenarios - PIN number only, fingerprint only or both - and as soon as the fingerprint became a non-issue, all subsequent testing at VA has been card plus PIN number.
DR. COHN: Okay. Thank you for the clarification.
So Judy, Harry, Steve. Jeff, you had your hand up, too, didn't you?
MR. BLAIR: No.
DR. COHN: What? (Laughter).
We'll go with Judy.
DR. WARREN: I am concerned that, initially, you had 50 physicians in this pilot. When it was over, more than half of them dropped out and asked to return to paper, and, currently, you only have two dozen with some new people coming in. So my question is why did 25-plus physicians request to go back to paper, and then what was the motivation of new physicians asking to join in this?
MR. SILVERMAN: Of the 50, there is a portion of that, I will guess about 15 - I know I have access to look up the exact numbers. There are 15 that never got off the ground, never got started with it at all. So they were out by virtue of - in one case, a prescriber that just declined participating from the start. A couple of them were hematology/oncology fellows who were identified among the 50 and we got everything set up for them, and before they did the first certificate issuance, concluded their rotation and resumed service at Loyola University Medical Center instead of at Hines. So the number of dropouts is not the 25 to 30, but I would say we probably had five to seven actual, thank you for letting me try this. I am not going to use it anymore, and that is uniformly a factor of the physician's level of comfortability with computers. This is by no means the world's easiest thing to just get a card and dip it in, and it is much easier now. Some of them would probably start now and have better success than with the system as it existed in October of ‘02. We have come a long way.
The people that want to join are the supervising attendings who have large resident clinics where they are supervising pharmacists, PA's, nurse practitioners, where they have a lot of prescriptions that they are supervising for the PA, pharmacist, NP, where in the paper system, somebody would be recommending, okay, I have just seen - and the same is true for resident physicians - I have just seen such-and-such patient in clinic. I believe they need these prescriptions. One of them is Schedule II. You are going to have to write that one and I can put the rest of them in the computer for your review and signature. So they like it because they want to do the one-stop shopping as well -
DR. WARREN: Okay.
MR. SILVERMAN: - and that is what prompts somebody to join.
DR. WARREN: Okay. And, then, did I hear you right that not every terminal could accommodate the smartcard -
MR. SILVERMAN: Yes.
DR. WARREN: - and that was a terminal specific? So if I am a prescriber and I am writing a bunch of prescriptions and I suddenly get this message, and I have to go find an appropriate terminal that I can do that in if I am going to do it electronically?
MR. SILVERMAN: As it stands today, exactly correct.
DR. WARREN: Okay. And then just - if you can give us a ballpark about how much extra time does it take you to set up that terminal.
MR. SILVERMAN: I've gotten it down now to - if I am going to do it, and, again, I have a familiarity with it that is not uniform.
DR. WARREN: Right. A knowledgeable installer of a terminal.
MR. SILVERMAN: A knowledgeable installer of a terminal can do it in under 15 minutes.
DR. WARREN: Okay. And then this whole process you had for registering the people seemed to be pretty ornate to me. How much time did that take, and resources?
MR. SILVERMAN: Originally, the process was probably - let's see, what are we dealing with? I would say in October ‘02, you'd be looking at about a one-week turnaround. What we have got it down to now is that there is still a one-week turnaround, but there is some lag time in there, and the lag time comes from the fact that within 20 minutes, I can get a provider, confirm their DEA number, get the thing signed, check their photo ID, all of that goes, acknowledge to PEC that we've got a prescriber that wishes to participate. They can confirm back, but they are only providing that database update to VA once a week right now. So if you asked me on a Friday, I would like to participate, by Friday, before we leave work, you are ready to go, and I'll give you your card next Thursday on the same day that the database comes updated.
DR. WARREN: Okay. And you were talking about scalability, which I thought was a wonderful thing to add at the end. You know, you were basically dealing with only 50 physicians here, and you start talking about some of them never got off the ground, some of them didn't make it through rotation, and especially in an academic medical center, what kind of support do you think you are going to need if everybody who has the ability to do Schedule II prescriptions is going to be needing these kinds of smartcards?
MR. SILVERMAN: The one thing that would address that the best is, right now, there's the process on the website where you go and enroll for your certificate, and that could be done at any of the enabled workstations.
I didn't go into each of the specific issues and bugs and gotchas, but one of the issues is that if you do the enrollment at a workstation, there is some extra cleanup that may occur about a year later that needs to be done, and so an ideal situation would be where you go to pick up your enrollment number and pick up your card and get that physical stuff would be a bank of computers right there for you to do your registration, and you do your registration right there, and all you are walking away with is your card that's got your certificate on it, and you know the PIN number to it because you just set it up, and in your pocket, your envelope with your enrollment number, in case you have to do it again, and you do that in a controlled area, and that would resolve a lot of the problems we had in the early going is if setting up the card was something you did, you know, kind of in the room next to where you turned in your credentials.
DR. WARREN: Okay.
DR. COHN: Okay. Harry.
MR. REYNOLDS: You didn't mention how doctors do refills.
MR. SILVERMAN: Schedule II's don't have refills, so we have not addressed that at all.
MR. REYNOLDS: I am not a pharmacist, so I didn't understand -
MR. SILVERMAN: Okay. Yes, that is a requirement of Schedule II prescriptions that they are non-refillable.
MR. REYNOLDS: Okay. If you step back from your - what you call PKI and everything, you are really talking about a certification process, a clear and precise certification process. You know who the person is and you have all agreed that they can do it.
MR. SILVERMAN: Right.
MR. REYNOLDS: And then you are talking about two-tiered authentication.
MR. SILVERMAN: Card and possession of it to open the card.
MR. REYNOLDS: Yes, or - yes, which could be a token, which could be whatever you want it to be.
In other words, once you set it up as a two-tiered, philosophically, you are talking about two tiers. You are using a smartcard or some people could use biometrics or others could use - so it is basically that whole idea of a clear and precise certification and a two-tiered authentication.
MR. SILVERMAN: Right.
MR. REYNOLDS: Which is the same thing on an ATM or anything else - So since you are a closed system, which you were talking about you like to live in a happy place. That is a happy place.
MR. SILVERMAN: Yes. (Laughter).
MR. REYNOLDS: Closed systems are happy places.
MR. SILVERMAN: Right.
MR. REYNOLDS: Get real ugly when you get - So you have heard us discuss - I think - Were you here earlier this morning?
MR. SILVERMAN: I came in during the - about the midpoint of Mr. Mapes' presentation.
MR. REYNOLDS: Okay. You heard us discussing the whole process of it goes from the physician through a vendor to, possibly, another vendor, then to a switch and then to the pharmacy.
MR. SILVERMAN: I did.
MR. REYNOLDS: And you have - obviously, with a closed system, you have a single format.
MR. SILVERMAN: Um-hum.
MR. REYNOLDS: You don't do any translations.
So since you do have experience and since you have been on the ground with this in reality, how do you see even your process - if you stepped outside a closed system and you had multiple players, how do you see your process working and how do you see the integrity from start to end staying in place?
MR. SILVERMAN: Okay. I don't think I understand the question -
MR. REYNOLDS: Because it works great in a direct transaction.
MR. SILVERMAN: Um-hum.
MR. REYNOLDS: As soon as you get middle players, that is where it kind of starts coming apart.
MR. SILVERMAN: My security background has all been gained as a result of this process.
One of the things that - even in the closed system - is useful to us - Let's see if this will get me to the right place. This slide here is where I described our closed system. We are getting an integrity check that is the process that creates a digitally-signed order to appear on the screen. That integrity check is what I see as the important part of transmission in an open system that, in some way, not only is there a prescription being transmitted, but something checkable. We'll use like the phrase check digit or check sum, probably more complex to that, in terms of all the fields of a prescription, but two things going on their way through, and any alteration to one would show up in the other.
So what I see for that - and I am addressing the question you are asking - is that the pharmacy and the standard - the standards designed to facilitate this electronic transmission would have to settle on what is our - first of all, what is the format of allowable transmission, and then each pharmacy system looking to accept it in would adopt that format in terms of, I know, according to the standard, how to verify the integrity of the prescription on the way in, because there is potential for those packets to be intercepted over whatever these open transmissions are - call it the internet, per se - and as long as they can be validated against what it was at the time of transmission, that is what I see to be the case is that the receiving pharmacy will have to adopt a set of standards of how do I know what to check.
MR. REYNOLDS: So, using your screen there, it could - philosophically, when that screen came up, it could show four digital certifications, if it went through four other people, or somebody could own that and you could audit them knowing that they would have - other words, somebody got it from the doctor. So that is your original start. Then that vendor sent it on - okay - and at some point they have to say it was okay and now I got it. I'm in charge.
MR. SILVERMAN: Um-hum.
MR. REYNOLDS: And then it goes to the next one and they translate it. They said, I'm in charge. So, at some point, the pharmacy has to decide who is in charge, because the whole point of this thing is that it used to walk in with a signature.
So I am not asking you to design it. I'm just trying to understand any non-closed system. If there is a succession of I got it. I'm verifying it, and the original thing from the doctor still comes through, but everybody else kind of checks it - I got it. I got it. I got it - and that pharmacy - I don't know how that works, but that whole digitally-signed says somebody owned it. They owned it under your certification, because you are the keeper of the certification, and it got to you and that wasn't tampered with. That is what we are - right? That is kind of the process.
MR. SILVERMAN: Part of the - even in the closed system that provides this statement, digitally-signed order - is the prescription came through with the digital signature affixed to it. That is just a string of characters and codes and stuff that come through. It also has to go out and check against what is called a revocation list or a revocation authority. Is the certificate used to sign that still valid? So, for example, if you ordered a prescription yesterday - yesterday morning - and yesterday afternoon you were found convicted of fraud in prescribing from a case that has just completed and your certificate gets revoked, the system is going to check that and it is going to say, there is no valid certificate behind what signed this thing, and that is actually a failure, even though it was validly signed, it was signed by something that wasn't valid anymore.
MR. REYNOLDS: So that speaks a little bit towards if you had a DEA number or something else focused on it, then you have a national place to check -
MR. SILVERMAN: You have a national -
MR. REYNOLDS: - regardless of where you are and how many steps it goes through.
MR. SILVERMAN: You have a single standard to check, and I think the other part to that is we are a closed system. Point A to Point B, that is all you get. It probably is appropriate to say if the pharmacy system is checking its immediate predecessor - that is a vendor in one of these cases - that is what it is responsible to check. Check that last part. Everything else is chain of succession -
MR. REYNOLDS: That is where I was going. So if there is an audit trail through the succession -
MR. SILVERMAN: The last one becomes sufficient.
MR. REYNOLDS: Okay. So that digital signature may be from RX Hub -
MR. SILVERMAN: Um-hum.
MR. REYNOLDS: - or may be from somebody - not necessarily the physician, which is different than now, because you have to have the signature for that.
Okay. Thank you. That's helpful.
And, again, we are not - I am not asking you -
MR. SILVERMAN: Yes, I can't design it.
MR. REYNOLDS: I'm not asking you to commit to it. I'm trying to understand -
MR. SILVERMAN: No.
DR. COHN: Okay.
MR. REYNOLDS: Since you are alive and well and have done it.
MR. SILVERMAN: Right. All you need to do is ask me to test it.
DR. COHN: Okay. Well, I think we have Steve as the final, and then we'll break for lunch after that.
DR. STEINDEL: Yes, Simon, I'm standing between us and lunch and I'm hungry, so I am going to turn this more into a comment than I will a question.
But what I have observed during your presentation is, first of all, there is a rather limited number of physicians who are involved with this, and I assume there are much more than that at Hines who do prescribe controlled II substances.
I would also assume - I think you made the comment that you see - and not one week goes by without seeing a controlled substance ordered using this system. So I assume there's a lot of controlled substances still ordered by paper at Hines.
Then I also observed, like Judy commented on, a really rather elaborate certification and maintenance system on this - card readers that need to be swapped out, changed, changes in software, et cetera - and this is in a closed system at one VA, and then I am trying to project this as it goes out to 172 VA's, thinking about the problems that we may be seeing - you know - passing this through 172 VA's.
And then getting into Harry's question, where we don't have a closed system, and we are introducing whole new -
As to what - and I am trying to picture what could be the cost benefit of going to this type of system over something that is going to be less elaborate.
The comments have been made in the past - and I have been one of them that makes it, because CDC runs a closed PKI system - is that, in a small circumscribed environment like you are working in, you can operate a PKI system. It takes some overhead - sometimes, some substantial overhead - but the extrapolation to a non-circumscribed system is very difficult, and that is just my observation.
And, Simon, if we could have just a comment back, but, you know, as Simon indicated, we would like to be brief.
MR. SILVERMAN: I'll be extremely brief about that.
In your final comment of that, you described the term overhead, and that is how I perceive the progression from late 2002 to where we are now. Initially, it was an hour setup or we found a bug or it didn't work, and all of that has gotten down.
Each of these are effectively one-time things. There has been a turning point at which the system became stable and we can add practitioners and add workstations ad lib, and so, for that one facility, a huge learning curve, per se, to get to that point. The second facility won't have to go through that. Still closed 140-170 VA's depending on how you like to count us. Second system can go straight on from there. Third system can learn from there that by the time you really are scaling it is a single day or a single week or however you want to manage your hardware rollout. Roll it out, get everybody authorized and then you are stable for a year or the expected validity of a certificate, which is a year or until your DEA registration expires, whichever comes first.
DR. COHN: Which is three years, as I understand.
MR. SILVERMAN: Correct. It's three years, but it might come up on - you know - within the one year.
DR. COHN: That's right. Okay. We will continue this conversation.
Now, I am going to suggest we break for lunch. I am going to try to get us back on schedule by starting at one o'clock. So it will be a slightly abbreviated lunch, but Steve knew his last question was between us and lunch. So - Anyway, we'll be back at one o'clock.
MR. SILVERMAN: Thank you for the chance to speak.
(Luncheon recess at 12:15 p.m.)
Agenda Item: E-Signature: Authentication and Non-Repudiation
DR. COHN: Our first afternoon session is really, I think, a chance to talk to the industry again around all of the issues related to authentication and non-repudiation, and we are obviously delighted to have you joining us to talk some more about it. I think we have all really had a chance to - hopefully - get a little smarter and learn a lot, both in previous hearings as well as in the sessions this morning. So we are obviously delighted to hear more about your thoughts as they have progressed.
Now, I think we are going to be - are we going to be going per the listing here? Yes, I think, right now, we have David -
MR. MEDVEDEFF: Medvedeff.
DR. COHN: Thank you. Florida Medicaid start leading off then, and then we'll go from there to - and then Jack Guinan, Mike Simko and David Kilgo. Okay. Well, thank you. Please.
MR. MEDVEDEFF: I'm David Smith. (Laughter). My name is David Medvedeff, and I am Vice President of Clinical Programs for Goldstandard.
Again, thank you for the opportunity to present.
A few months ago, at one of the committee meetings, we gave you an update on what was happening in Florida Medicaid, and, specifically, what the program looked like and how it rolled out.
So, today, what I was asked to do is provide a high-level update on where we are at in Florida Medicaid and then speak to the fraud-and-abuse authentication and non-repudiation issues.
First, I would like to speak on the update on Florida Medicaid and where that program is at.
If you recall, at the first meeting that I testified, this program started in the summer of 2003. It was targeting 1,000 of the highest Medicaid prescribers. It provided Medicaid's preferred list, a clinical-drug database and a 60-day prescription history at the point of care for high-volume Medicaid prescribers in an effort to enable that doctor to make better decisions having good, sound clinical data specific to that patient, and, more importantly, irrespective of the other prescribers caring for that patient, driving better continuity of care.
Because of the results we had in the first phase of this program, from 2003 to 2004, and the return on investment, both clinically and financially, that the state recognized, the program was expanded in late 2004 to include 3,000 of Medicaid's highest prescribers. It was also expanded to give that prescription-history view from 60 days to 100 days, and this was done to give the doctor a seamless clinical view of that patient's drug therapy from visit to visit if that patient had a chronic need. So the doctors - Medicaid were telling Medicaid and telling Goldstandard that they see their patients every 90 to 100 days, and if they could see a seamless view of that drug history, then this would be helpful, and the program was also enabled to include electronic prescribing.
So what is the status of the program in Florida? We currently have 1,500 doctors registered to participate. We have 1,300 active users, 1,300 PDA's out in the community being used every single day, and we are adding about 200 to 300 doctors every month through the balance of the spring to bring this number up to 3,000 total providers in Florida using electronic prescribing and technology at the point of care.
All of the prescriptions that are being routed today electronically are going through SureScripts, and we have also enabled this to include a multi-payer source. So, now, the doctor sees not only Medicaid fee-for-service patient data, they also see Humana patients, Staywell(?) patients and other payers that we are working with, so, essentially, taking all that data from multiple sources and pushing it down to the point of care.
Some of the other developments - just giving you a high-level background on what is happening in Florida - about six weeks ago, Florida announced a new collaborative that has been developed. It is known as the Florida Behavioral Healthcare Collaborative. This is focused on educating prescribers, particularly in the mental-health arena, on the appropriate use of medications in trying to drive better continuity of care between the general practitioner and the specialist. Goldstandard has been brought in to be part of this with Florida Medicaid leveraging technology to do this through electronic prescribing.
Everything I have just described to you, as far as the rollout of this and how this is being implemented in Florida, will also take place now in Mississippi beginning next month, and we are in further discussions to incorporate all the lab data around Florida Medicaid and potentially in Mississippi, to start pushing out labs along with electronic prescribing.
So that is the update, and what I would like to do is take a few minutes to speak to the issues of fraud and abuse, authentication and non-repudiation.
When I was asked to testify, I really wanted to set the scope, because fraud and abuse, in particular, in the Medicaid world, takes on a totally different scenario than fraud and abuse in the technology world. So fraud and abuse can be viewed either at a patient level, at a prescriber level, at a pharmacy level or it can go as far as identity theft, which are some of the issues around authentication; and the non-repudiation is really focused on the integrity of the data and the confidence that when the data leaves the doctor's hands it is the same data that gets to the pharmacist's eyes in the pharmacy.
So let's talk about patient-level fraud and abuse. This is your traditional view of patient-level fraud and abuse, and what we have on this slide is one patient who received about 15 or 16 narcotics in the span of about 60 days, and before technology, this was very easy to do, to gain the system - in a Medicaid program, in particular - and, now, using technology, doctors at the point of care can identify fraud and abuse at the patient level.
This is a slightly different view, and this is an HIV patient who, again, on 30 different medications, but what you don't see in this is that, now, a doctor at the point of care can identify that the patient is receiving a therapy they did not prescribe, has a very severe drug interaction with their current therapy. It is coming from a different doctor, and what it turns out, in this case, is that this was the partner of an HIV patient who was using, fraudulently, their Medicaid plan to pay for their partner's HIV medication. So, again, defrauding the system, and technology now can enable that.
And then we get to the issue of identity theft, and this is actually an email that was sent to me by a pharmacist that works for Medicaid out in the community, and what this email basically is describing is that, now, using technology at the point of care, this doctor identified that a patient stole a prescription pad and started writing themselves and their friends prescriptions, and the doctor was receiving this data on their PDA.
So when you get to the issue of fraud and abuse, I think, technology almost enables kind of a check and balance in a system which may be more useful than worrying about the authentication aspect on the front end, and I'll speak to that in a couple of minutes.
So addressing authentication - and what I would like to do is just really shed light on how we address that in Florida.
The user-name and password issue is only handled by the end user. So only the prescriber that is using the application can change or manage their password. The way that happens, all of our provisioning and training of the device and training on the application is done face to face. All of the data entry, as far as user name and password, is done electronically only by the prescriber, and none of that data is stored on any server that we have access to, that the state has access to, and the only way that user name and password can be identified is using our partner, Verisign, through one of their hosted facilities.
We go as far as if that doctor calls our help desk, the help desk can identify the doctor through demographics, can ask a challenge question and challenge answer. The doctor has to first choose the right question and then the right answer, and then we can provide hints around that password, but only that provider can select that password, and if we come to a point where they cannot remember their password, we start all over again, and the doctor has to reissue a new user name and password. It is the only way that we are comfortable, kind of in an ivory-tower sense, that that doctor is the only one who knows what that user name and password is.
Now, let's get to the reality. We get PDA's returned that have a cracked LCD screen, and you flip the PDA over, and, literally, scratched in the plastic is the doctor's password.
You walk into a doctor's office, and the doctor signed all the documentation saying they understand how important securing this password is, and they actually have thumb-tacked on the poster board behind their receptionist their user name and password and the application.
So, the industry, as a whole, takes user name and password very seriously and the authentication issue very seriously, but it has bene our experience, working with, now, almost 3,000 doctors, that some take it very serious. Some have their entire system and operations in their practice setup, so that all of their peripheral support is using the application.
Now, to the issue of non-repudiation - and I am not going to belabor this point, but, really, this is taking the data that is within a secure transmission and further encrypting that, and so what we have done in Florida is we have actually implemented a PKI solution. Now, this is only carrying the water part of the way, and what I mean by that is to have true end-to-end PKI, you have to have PKI from the vendor perspective, so when that data gets transmitted from the doctor's hands to our server, we have to be able to read that and authenticate that message. From the vendor to then the gateway, you have to have a PKI in place, and then from the gateway to the pharmacy, you have to have PKI in place.
Today, I would argue that the vendors are probably the most nimble in being able to implement this as we have, but I could tell you that the reality is I don't know that the Titanic is going to move that quickly. So probably a bad ship to use there. (Laughter).
So, you know, the reality is the end-to-end adoption, as I said. I believe if we come to - as an industry - we come to the conclusion that PKI is the only way this message can be taken from the doctor to the pharmacist, it is going to slow this uptake that we are starting to see across the industry with electronic prescribing, the use of VHR's and EMR's, and there are other solutions out there, and what I mean by that is, now, the doctor has new data in their hand, and that is claims data. So I am a prescriber and I write a prescription for Drug A, I get feedback that Prescription Drug A was the one received at the pharmacy and it was received for this patient. You could argue that is almost non-repudiation. You didn't necessarily have to have a very robust technology to non-repudiate that the message that was sent was the same one delivered, but when you send the message back to the doctor that says, we received Drug A and we filled it for Mrs. Smith and it was exactly the way you prescribed it, the doctor knows that - in real time - that message was there and it was exactly what that doctor intended to write.
So I think the use of SSL, the use of the secure transmission ports and also the use of this new feedback data that otherwise wasn't available before technology is one way that we could allow this industry to mature before we put in these guidelines that are very restrictive.
And that is my presentation. Thank you.
DR. COHN: Thank you, David. Thank you very much.
Jack.
MR. GUINAN: Yes. My name is Jack Guinan. I am the CTO of ProxyMed. Thank you all for having me again.
For those that don't know me from previous times here - we have about 4,000 physicians doing e-prescribing on our network - I am going to speak to, again, authentication, non-repudiation and give you all a sense of what we are doing along those lines from a very pragmatic approach.
As far as authentication goes, the way we look at it, how do we know the person sending the transaction is, in fact, the person that we think that they are?
We do this through a set of business processes and then common access controlled methods.
I am going to go through - I have passed out - I'm sorry I don't have a Power Point Presentation, but I have - I believe they passed out a written copy of the testimony.
The steps that we go through to allow folks to use our network are as follows: When someone - a physician's office and a prescriber wants to use our network for e-prescribing, they are required to fill out a registration form and send it in to us, a physical form, with their practice information, physician information, and this includes DEA numbers for physicians that want to be registered on the network.
When we get this information from the practice, we bounce the information against the DEA database. As someone mentioned earlier today, we also get this on a very frequent periodic basis, being updated. We match all the information we get from it. As well, then, we call the practice, and we also verify the rest of the information. So there needs to be a physician's office that truly exists like on the piece of paper at that phone number answering the questions, and we have a script that the folks in our office use to figure out that, in fact, it is the physician's office.
Once this is complete, we assign our own unique identifier to both the practice and the prescribers at the practice, and these are given out to the end users. These ID's are entered into the software that is going to be creating and sending the e-prescribing messages.
So, then, as this practice who has been - I'll call it certified or credentialed by us and given access to the network, when they send their messages with those ID's, we look at these messages and make sure that the ID's do match up in our database, that they are registered and that the information in the message matches the information to those ID's. I'll get into the fact about opening the messages in a minute with the non-repudiation, but we do open the message, look, and the name of the clinic and the address inside the message needs to match what was in the registration information.
We have, in the past, implemented various tokens and other ways to know that the computer that was sending the message was, in fact, a computer that was registered, but I'll address that in a second as well. Those didn't fare too well, as computers changed quite often. So we rely on the fact that we getting a message with ID's that we know are valid ID's and were given to an entity that we manually and over the phone and spoke to people recognized as a person that was okay to send prescriptions to the network.
If we are sending these prescriptions on, then, to another network, this does not follow through to the next network, but we are then authenticated by that next network in line. So the onus is on the first network in the line really to authenticate who the practice is and the physician.
When we send the message on to the pharmacy directly and not through another network, like to Walgreens, who is present here, Walgreens relies on ProxyMed that we have done this authentication. They'll speak to their own authentication, but, basically, we have a system in place with log-ins and passwords that they know that it is us, and, in effect, are trusting us that we are fulfilling our obligation to make sure we are only accepting prescriptions from someone that we are supposed to be. So there is this concept of trusted entities that I'll get into as well. So that is how we perform authentication, how we certify folks to use our network.
Once we do get prescriptions, then, how do we know that - or there is a question raised, how does the pharmacy know that the prescription has not been altered once it is sent by one of these entities?
Well, the reality is is that - and, as we have told this group in the past, we actually do alter just about every one of the messages that comes through. NCPDP script is a young standard and not everyone is on the same version, and there are slight differences in implementation. So I would say that probably 100 percent of the time, when a message comes in, we open the message. We look who's sending it, where is it going, what format are they both on and what were the predetermined business rules that we established with our trading partners and agreed to up front to say we are allowed to do this sort of mapping between the various formats.
We do sometimes - besides reformat, there is a requirement to, in fact, change content of messages. Not everyone has implemented the same code sets on both sides, and so not for things like drug - we never change the drug that is being sent, the sig, but there are certain qualifiers in the NCPDP script message where people are using a one to stand for something instead of a two, and we have agreed, well, we'll change it later, but just map - everyone who sends a one in this field, map it to two for us, and so besides just the format of the message - not on every message, but on a good portion of them - there is some amount of the content that's changed. So, in fact, we wouldn't pass that test, and so that is one of our big concerns is that whatever is adopted here recognize the fact that today - and I believe this is the case with other players in the industry - but, today, for ourselves, to operate our business, we are required to actually modify the messages as they go through. So we would really like to see the - whatever is implemented here not restrict us from doing that. I don't know how we would operate if we were not allowed to actually act upon the messages that came through the network.
And so I believe the way that we are getting around this and the way that the trading partners in the chain are okay with this is that we have contracts in place between us, trading partner agreements, that set forth what our various service levels are, what our warranties are, what our liabilities are, and we have established operating procedures, interface specifications, again, what we are allowed to map and not, what we are required to actually reject at our network. So, sometimes, we might get a message into the network and when we open it up it doesn't comply with what one of our partners want, and they say, don't send me a message that doesn't comply with what I want. Sometimes, at the clearinghouse, we actually reject messages back to the sender, because we weren't able to map them to where they went, and we do this under contract with our trading partners.
And so if you - for those of you who have this on page three of the document, maybe to follow easier, there is a little picture, but, as an example of how complicated this gets, there is a situation where you might have a medical-manager physician using a handheld in their office and they are writing the prescription. Well, that prescription is traveling from the handheld, first of all, to a centralized computer in their office. So it doesn't go straightaway out of the office. That computer is hooked up to the Web MD Network. So there's an interface there. The Web MD Network, in turn, passes that prescription along to our network. Now, I am not going to speak to what they do, whether or not they open or modify the messages, but when it gets to us, like I just said, we do that. Well, if this prescription is going to Publix, for instance, it goes from our network to eRx's network. They are an aggregator, a network provider, the same that we are, more so on the pharmacy side. The eRx network does open, and, again, modify again the message to what they have to with their trading partner, Publix, and so then eRx sends the message on to the Publix central host system, which, in turn, then, passes the message along to the in-store systems at the end of the chain.
So you can see in this one example - and there's many more examples like this - that there are five entities involved, but, actually, seven different steps along the way that the message had to be passed along.
If there was to be implemented a PKI implementation that required an authentication of the certificates and the kinds of real-time validation of certificates at each one of these steps, we are talking about creating a huge amount of traffic in transactions that need to happen as overhead on top of getting this prescription along, because to make sure that - you know - we are allowed to deal with this - let's say that we have the private key and we are going to decrypt this message. Well, entailed in this technology is hitting some CA system or somewhere to make sure that the certificate is valid and that it is following the rules.
So there are literally dozens and dozens of these kinds of situations with this complex web of participants, and so to implement a technology like PKI that was talked about this morning would add a huge amount of complexity. I know that we are not there. It would be very hard for us to implement that technology in this picture with our partners, and I know that most of our partners would also find it difficult. So I don't have an answer, but what I came to say really is that we would like to make sure that whatever solution is proposed allows this kind of traffic, because this is where the industry is. Maybe it shouldn't be this complicated and maybe it won't be this complicated in the future, but if this is where it is today and we are going to use this as the foothold to get the initiative going, we need to make sure that the business players that are in it can keep doing business the way we are and we will evolve with whatever comes along, but this is a very real situation.
My next point that has to with authentication, non-repudiation technology, it has to do with the cost in the physician's office and sort of the intrinsic burden of security in that - and my point is that e-prescribing is just one of many, many functions that will go on in a physician's office, and many computer applications that are in a physician's office, and physicians' offices, like many other mostly small businesses, can't afford to do things six different ways. They need to do things one way. HIPAA was quite a burden already imposed, and most people are still struggling in small physician's offices to meet what will be the security regulations coming this year to implement just log-ins and passwords for every individual and not share log-ins and passwords. This is a big burden already.
So to have e-prescribing come in and say, I know that for all the rest of your systems, you are using log-ins and passwords and your own internal security policies, and that is good enough for all of the rest of your HIPAA-covered transactions, but to do e-prescribing, you have to now learn what a digital certificate is and know how to implement it and get it registered and when they expire to renew them and when it doesn't work to add the support.
I would say that most likely they'll say, well, then I'll pass on that for now, because I have enough on my plate, and it is going to have to fit in with the level of security technology that is present in the general systems in the physician's office. So I think - especially, you know, at these hearings we are talking about e-prescribing particularly, but in talking at a number of other organizations and other initiatives going on, we are all just struggling with getting basic access control put into physicians' offices under HIPAA, and that is to have everyone get a log-in and a password that changes periodically, to have lock-out involved, all of the things that are inherent in the HIPAA security regulations.
So our recommendation for this is that we look to the HIPAA security regulations and the way that the vendors in the community are implementing HIPAA security regs into physicians' offices and try to make whatever is recommended here go along with what is happening with that initiative, because there is a huge amount of effort there, and I am just afraid that since e-prescribing, again, is a small initiative compared to getting paid in a physician's office that this will get put on the side if it seems to be too much of a hassle when they have these other efforts to worry about.
So, then, a little more specifically with - oh, I'm sorry. I also wanted to say that, in the past, we have tried to distribute client-specific digital certificates and so that at least at each office they had their own digital certificate and that was a way, again, to authenticate who they were.
Unfortunately, this effort failed. We tried this with our entire customer base with our own software project of about 1,500 physicians. I guess it was about 500 practices. We distributed the digital certificates. We went through the whole effort of helping them to get installed on the PC's and get registered. Primarily, this was a Windows environment. That was a lot of cost to us to both distribute and then support the effort.
Well, started immediately. They got a new computer system in their office the next day. How do I get the digital certificate on the new computer system?
The computer system breaks. The vendor comes in, wipes out the system, reinstalls the software. The digital certificate is not there anymore.
We had a flood of support calls, and we had many, many of our customers not able to use the service because the security was stopping them from using it, all inherent in the fact that there is some amount of skill involved and training involved to be able to install, administer digital certificates in a Windows environment, and, again, I am speaking to the small physician practice and maybe group practice that has offices with 5-10 physicians in each office. They just don't have the staff there to administer this type of technology on an ongoing basis.
So we did try this on more than one occasion, and we went back to log-ins and passwords and trying to force people to change their passwords as they are supposed to do.
So if - again, if this kind of technology came back around, it was mandated, well, we wouldn't like that very much, because history has a way to repeat itself. I don't think much has changed in the marketplace since we tried it last time.
So, then, just a few recommendations. We recommend that the goal of authenticating the parties involved in electronic prescriptions be accomplished through a combination of business processes, as I discussed, as well as some basic access control in the form of log-ins and passwords that we spoke about.
We also recommend that, as opposed to encrypting and putting a hardened package around - message, that we work on securing the communication channels. That is much easier. We have no problem in putting whatever sort of security technology is required to secure the communication channel. Most of us in the business are already doing this, and, under HIPAA, any of us that are covered entities are already doing this.
We specifically, as I said, would not like to see a PKI implementation, because we believe that it would pose too much cost and burden and probably be a real stumbling block to getting started.
We do support the NCPDP's stated definition of electronic signature which has an electronic signature being any electronic sound, symbol, data string or process attached to or logically associated with a record that goes along with what I have been saying on our practices, and, as I said, we propose that you make sure that the HIPAA security regulation dovetail into whatever it is that is being proposed for the implementation for this.
Thank you very much.
DR. COHN: Okay. Jack, thanks very much.
The next presenter is Mike Simko, Walgreens. Oh, David.
MR. KILGO: Good afternoon. Mike and I are going to work together -
DR. COHN: Oh.
MR. KILGO: - we face some of the similar issues in the retail industry.
And, again, I am David Kilgo. I am Director of Third-Party Operations with Walmart. I have been a pharmacist for 25 years and almost 20 years with Walmart.
MR. SIMKO: Mike Simko with Walgreens, Manager of Pharmacy Systems.
MR. KILGO: And we were asked to come and talk about the current position of pharmacy today with non-repudiation, e-signature, and in terms of how we manage that, and what we would like to talk about first is kind of the present state of the industry, the present state of what our pharmacists face on a day-to-day basis in our current paper environment and how e-prescribing is such a leap forward in that environment.
And, today, in our pharmacies, we have a paper-based system, and you think in terms of validation of the prescription. How do I know this is a valid prescription for a valid patient? You deal with written prescriptions that come in fax prescriptions and telephone prescriptions. The fact that a written prescription can be difficult to read, authentication can be difficult. A popular trade journal routinely has difficult-to-read prescriptions, the purpose being to encourage validation through telephone calls and confirmation, but they are very difficult to read.
If you practice around a teaching institution where you have one prescription blank that maybe many different parts of the institution use, validation after hours is very difficult. Very difficult to find the part of the institution that the prescriber came from. Many times, it's a little difficult to identify exactly who the prescriber is.
Phone prescriptions, you deal with look-like, sound-alike drugs, and also elaborate schemes that you see that many times people will do to divert drugs.
And I may recognize an office person as belonging to a physician that I have a good relationship with, that I commonly see prescriptions from, but yet I still do not have a verification that that prescription was, in fact, ordered by the prescriber.
A fax prescription, again, takes all the issues above and just adds another complexity to it.
The prescription itself, critical information may be missing. It is routine to see prescriptions missing quantities, directions, signatures.
Patient identification is difficult. Very important to match the patient that you receive the prescription from to a profile in your practice management systems in a written environment because of the information that may be lacking. Compromises your DUR efforts and also is very frustrating to your staff in terms of getting claims submitted properly.
Very important that minimal information be included - the name, the address, birth date, sex of the patient.
And, also, many times, you must rely on the person that is not the patient delivering the prescription. I think in terms we have a very ill customer, a very ill patient who is - have a care giver that would be delivering the prescription to the pharmacy.
All of these present challenges for our pharmacy staff and for our pharmacists to deal with.
And think about in terms of how the electronic process addresses those. We look at every one of these steps along the way where there is a critical opportunity, e-prescribing deals with that through the written prescription, the phone or the fax. The e-prescription consolidates into one method, so that you have confidence in the message you received.
I spoke to one of our pharmacists this week who is actually leading our group in terms of having electronic prescriptions or receiving it and said, Has there ever been a time when you had any concern or any problems with knowing that that prescription was valid? And her answer was, absolutely not, that she had extreme confidence in the system, that she loved it and her practice peers on the other end - were sending the messages equally loved it as well, but there was absolutely no opportunity for any integrity issues with those messages.
The patient ID, again -
MR. BLAIR: Those messages resulting in a fax -
MR. KILGO: No, they were actually flowing into our practice management system electronically. They were - never used a paper until the very end of the process. So an electronic message comes directly into our practice, our pharmacy-management system as an electronic message, right into our workflow, so that there is never anything put to paper until the very end.
So, at that point, Jeff, all our pharmacist has to do is make sure that the patient that they are adding it to their profile matches the demographics that they have on record for that patient, and if there's differences they can readily update it, and the same with the prescriber.
But, again, e-prescribing deals with all these, and it is inherent in the design of the process dealing with all these, so that the demographics of the patient is copied into the message and sent along.
Authentication of the prescriber, again, issues for pharmacy. In today's environment, customers travel great distances. It is not uncommon even to see customers maintain a relationship with a prescriber that was in their favorite town maybe hours away. It is also not uncommon in a rural environment that a customer may travel a few hours to go to a specialty that they need care, and familiarity with that prescriber is an issue. How do I know - do I get enough contact with this prescriber to have confidence that the prescriptions I am receiving on paper are, in fact, legitimate and from that prescriber, and, yes, it is the pharmacist's responsibility to make those validations, but, yet, I'm sure any pharmacist in the room, you have been duped a few times over something that you thought was very valid, but yet it turned out not to be.
Preprinted prescription blanks, stamped signatures all are challenges for us. Again, touching the large clinics - and I don't mean to beat up on the large clinics, but, yet, it is a unique opportunity in the metro areas, especially where that you have a large proliferation of customers, especially if you practice in an area that need the care offered in those environments.
You deal many times with stolen and forged prescriptions, and, also, again, with the content.
Registration of new prescribers in an area is another big challenge of how do I know that the doctor or the nurse practitioner that I have just received a prescription from - maybe across town, maybe in the same neighborhood - is, in fact, a legitimate prescription, and, again, e-prescribing deals with all of those.
And if you look at the next slide - I'm sorry I didn't let my Power Point keep up, but e-prescribing deals with each one of those through inherent designs of the system. The network is secure and gives confidence to our pharmacist. The SureScripts, SPI or SureScripts provider ID provides the validation on the front end to ensure that the authentication of the prescriber is valid. He is who he says - he or she is who they say they are and they have their credentials supporting their action there.
MR. SIMKO: More thoughts on the security side. It is true that pharmacies, at least chain pharmacies, they generally connect through a central server, and that gateway goes out to an aggregate or, in this case, such as ProxyMed or SureScripts, and we rely that the physicians that - or the prescribers that they are registering on their system that they are registering an actual prescriber and that that connection is secure between the prescriber and the aggregator.
The pharmacy is still wholly responsible that that physician and that prescription is valid. We are relying on them maintaining the secure connection and assuring us that that connection is - what is sent by the prescriber is what is received by them and what is received by them is what is sent to us; but, nevertheless, the validity of the patient, the relationship that a true doctor-patient relationship exists and that that prescriber is able to write prescriptions for that particular medication still are relying on our pharmacies and our pharmacy host systems.
Physician registrations are assigned a unique identification number. We track prescribers based on those unique numbers with our host-pharmacy system, and, again, there is an electronic log of all transactions that take place.
Just to mention a few things on the security side, we have had very suspect prescribers that would never write a prescription, and we noticed that the only prescriptions we would get would be phone-in prescriptions. They are only given orally, and when, you know, it was offered to them that, you know, why are you not writing prescriptions? they would say, well, you know, they just don't want their patients to have to wait, that they can just phone the prescription ahead of time, their patients can get the medication quickly. We suggested e-prescribing, and, in many cases, a lot of them didn't want to participate. So there is just - you know - no trail for the pharmacies at all to authenticate an oral prescription, outside of knowing the prescriber and maybe knowing who works in the office, but you have no authentication of any particular prescription that was transmitted to the pharmacy.
Electronically, we have logs, and we have used those logs in the past for an authentication purpose.
The other important piece is the integration of e-prescribing and the host-pharmacy system, and, again, the pharmacy system validates prescriber registrations. We know who a valid prescriber is. We have them registered in our system and we know who a valid e-prescriber is, and those people are registered in our system. Again, we assign unique ID numbers to those physician registrations.
Firewalls are built around our host-pharmacy system, so no one but who we approve can transmit anything to us, and so in the case of aggregators, such as ProxyMed or SureScripts, those messages have to come from them. No one else can send us medication orders.
Variety of ways. You can use VPN or SSL lines, and then, again, the pharmacist is ultimately responsible for proving the validity of that particular drug is appropriate for that patient, and, again, we use our host-pharmacy system in connection with our relationships that even after a message is received that patient, that physician and that prescription are all validated.
As far as pharmacy and aggregators, our recommendations are that, again, secure connections are used, direct lines, SSL and VPN, private-data circuits, encrypted messaging. Jack Guinan mentioned, you know, the HIPAA standards, and then standards that prevent altering prescription transactions, which is like NCPDP script.
The pharmacy side, existing firewalls that are in place are working very well. Unique pharmacy identifiers with NCPDP numbers, prescriber ID numbers, the elimination of any authorized access and the keeping of log files for all transactions.
Again, you know, the blend of all this technology has really shown to be beneficial as far as not only the timely receiving of medication orders for patients, but - and, as mentioned before, you know, the critical pieces of all the prescription is in place. We don't get prescriptions that have incomplete information, and any prescription we get electronically, you know, we have full confidence that our trading partners, such as ProxyMed or SureScripts, are protecting the integrity of the system up until when they get that medication order from a particular prescriber, and, in turn, our connection with them has that same kind of confidence built into it, so that when we get medication or electronic prescriptions transmitted from the aggregators to our gateway to our pharmacy network we know that that is a secure connection and we know where it is coming from, and, again, as far as the host-pharmacy side, we have processes in place to know that that particular prescriber, that particular patient, then, for that medication is valid, and it is still incumbent on the pharmacy and the pharmacist that they do that validation process.
So, you know, parts are all in place that ensure the security of the message, and the process is in place in the practice of pharmacy that that is the appropriate therapy and that is a valid prescription, and I know, you know, we have heard a lot of testimony today about authentication and non-repudiation. We trust the electronic network far more than what we are dealing with with oral prescriptions today, and especially the case of controlled substances. They can - you know , Schedule III through V's can be phoned in to a pharmacy and we have no method of proving where those came from, and especially in today's pharmacy-practice world that many patients no longer just go to their corner drugstore. Oftentimes, they'll drop a prescription off near where they work or near where they saw their physician, but not necessarily near their home. So, often, in today's society, pharmacists are losing the very personal contact with a particular physician, and, no, we don't know that a certain doctor uses blue prescription blanks or some other color. We are relying on the fact of technology and secure connections, and it is that interplay between that technology leading from the physician's office, those secure connections and our relationship with those trading partners that make electronic prescribing so far superior to the processes that exist today, and while PKI may, at some point of time, for some very small segment of prescriptions - i.e., Schedule II drugs - we think that - you know - Schedule III, IV's and V's, if they are allowed to be transmitted orally today, this is a much more secure method of doing it, and we feel highly confident that those would be valid prescriptions and anything that would be unauthorized, invalid - and, again, those have all the procedures to be checked by both a physician's office and the pharmacy - would not be utilizing that system for it.
MR. KILGO: Some thoughts and conclusion. The paper-based prescription today, as we see it, poses many problems. I think we all agree with that.
The security intrinsic in the SureScripts system has been adequate to ensure authentication, non-repudiation.
Again, back to my pharmacist who said, yes, I know where this came from, and the good news is that that physician also knows that we receive it. So there is a variety of handshakes along the way as the data passes from location to location.
There is no immediate need for digital signatures beyond the current validation process. The security built into the system and used by retail today ensures that these signature requirements are less urgent, and the requiring digital signature, at this time, could potentially slow the progress that we are making, and we are making progress. I look at the number of prescriptions that we are receiving electronically week to week, week on week, as we add new states, and it is quite impressive.
Pharmacy-practice systems. We maintain and recognize valid prescriber registration information, recognize that it maintains accurate patient information, and with the e-message, that information is compared, so that there is a valid authentication there.
Integration of the e-prescription within the practice-management system many times just flows right into the work processes, so that it becomes a step of efficiency for the pharmacists and their staff.
The security of the firewalls, secure networks, restricted access and HIPAA compliance as well, and, then, looking at April when we have another layer of HIPAA security coming in place adds more security into that environment.
Important things to keep in mind is there is no substitute for the pharmacist's professional judgment. Talking about some of the things our friends at Goldstandard were addressing earlier where the passwords and such were taped to the PC's or on the back of the PDA's, that is real world, unfortunately, and even at that point, the pharmacist is still the gatekeeper of that prescription getting to the public and the use of their information, the use of their skills in relating to the patient, reviewing profiles and counseling patients and knowing their patients.
And, lastly, there is no perfect system. If we wait for the perfect system we'll be waiting a long, long time.
MR. SIMKO: Any questions?
DR. COHN: Oh, I suspect there will be some questions.
Actually, I want to thank you all, I think, for what has been some very useful presentations, and I suspect that there'll be questions from the subcommittee.
I actually have one just to ask David Medvedeff.
MS. FRIEDMAN: David Smith.
DR. COHN: David Smith, okay. (Laughter).
I apologize. You're going to have to get a new chair, since I can't seem to pronounce anybody's name.
But, David, you alone of all the testifiers appear to be using – successfully using - maybe using PKI in your application. Help me with this one a little bit, because I think what you described is is that you only use it between the provider and your server, and, after that, you make no pretense. So I guess that was question number one, did I understand that right?
And, number two, is if, indeed, you are using that, what sort of controlled-drug-substance policies and use do you have in Florida in relationship to your systems.
MR. MEDVEDEFF: Sure. First, we are using PKI. We are using it, again, only from the provider to our server before it gets to the gateway.
Now, it is in a place where we could take it end to end, but the industry is not ready to receive that end to end. So in order to keep that data so that it is in a useable format when it gets to the pharmacy through the gateway, we have to remove that electronic signature, so it does not corrupt that data transmission when it goes from our server and beyond.
Now, we instituted the PKI for one main reason and that was the amount of misinformation that was circulating about electronic prescribing and where the regs were going to end up, and we view ourselves as a fairly innovative company. We weren't necessarily pushing for PKI, but if it happened, we wanted to be prepared, and we did not want to be left out in the cold, and so we went ahead and we are proactive in implementing that, but, again, it stops short where it is not end to end. It goes from the doctor to our server and then it goes through an SSL connection, a secure-layer connection, from that point forward.
Around controlled substances, because the DEA has not given guidance on that, all controlled substances are actually faxed back directly to the doctor, and the doctor then faxes the controlled substance into the pharmacy. So we have not instituted PKI, because it is not end to end, to enable us to do controlled-substance electronic-prescription transmission.
DR. COHN: Okay. And that applies to, of course, to II, but also to III, IV and V?
MR. MEDVEDEFF: Correct.
DR. COHN: Okay. Other questions?
Harry.
MR. REYNOLDS: Yes, I'll go with David first. I've got one for each, if I could. Is that all right?
DR. COHN: Go ahead.
MR. REYNOLDS: Yes, okay.
I really like the idea of the communication back to the physician. I think that is a strong comment about the closed loop.
Jack, I had a couple of questions. I struggle with mapping versus - in the record, because, as you think about non-repudiation and you think about truly receiving in a pharmacy what was sent, format mapping is one thing, content mapping to the end is another, and so if you could give me anymore words on that. That -
MR. GUINAN: I would say that the reformatting of the messages is by far the majority of the changes that take place, and I am trying to think of an example where we change the actual content for code sets.
For things like on refills, the way that PRN is handled on a refill, as opposed to a specific number, or, actually, some pharmacies - Okay. So when you send a refill request to a physician's office and they say, We are looking for three more refills, and then when they respond, some of the systems take the message going back itself as a fill of one with two additional refills where some of the systems will send back a message that actually says three refills.
Some of the pharmacy systems, when they are requesting three additional refills, want you to send back three. Others want you to send back actually the prescription plus two more refills. So we have business rules in place that actually map out, well, how many refills are the people really looking for, and those are the types of content changes that go on.
I do believe that a more fine-tuned implementation guide of the script standard could probably get rid of these content changes. I don't think it would be all that hard to have people agree on - There's not 100 of these points. I think there might be less than a dozen. NCPDP does a good job of pushing these kinds of things through. So I think that we could probably get away from having to change the content.
I think one of the concepts that is thrown out there is what is the intent of the prescriber, as opposed to exactly what did the prescriber send in the electronic message.
MR. SIMKO: And I think the other part to that is we have to do a better job of getting people nearer the same version release -
MR. GUINAN: Yes.
MR. SIMKO: – of NCPDP script, because it is anywhere from one to five.
MR. GUINAN: Yes, and some of the older versions don't support all of the values for the code sets, and so there has to be a translation of, I know that you sent a zero in that field, but, on the new version, you are supposed to send a one. So we'll go ahead and change it for you.
But I believe that this can be handled through having NCPDP put out a more fine-tuned implementation guide.
MR. REYNOLDS: And for David and Mike, I have a problem with your comment on Slide 11, second comment. If I listened to your SureScripts discussion of authentication, you have - is it not true that you have assured non-repudiation that it came from a doctor's office, not that it came from that doctor?
MR. KILGO: True.
MR. REYNOLDS: Okay. That's - I thought it was a little stronger than what the true definition of non-repudiation would be. It says, I did it, or, They did it, or, Somebody else did it for me, or something. So -
And the other thing, you mentioned one - that you have a SureScripts provider number, and so does a physician have to have multiple provider numbers depending upon all the different systems?
MR. GUINAN: At the moment, a physician is registered on one or the other of the networks out there. A physician doesn't participate on more than one e-prescribing network.
MR. REYNOLDS: But if the patient - and back to the idea earlier. If a patient drove two hours and then was going back home and that physician had to order that drug and the patient wanted it sent to a pharmacy at home, which is on a different network, that network doesn't know that doctor. That doctor is not signed up on that network, so how do you, as the industry, see - because - I mean, living in an area where Duke is, there's a lot of people that join us at Duke and then go home.
MR. GUINAN: I guess when the patient was at that physician's office the few hours away, the decision to send the prescription electronically really has to be made at that time, because if they are not going to, then they have to hand the patient the prescription, and so - I mean, that physician that is writing the prescription is either on a network or he's not.
MR. REYNOLDS: And, also, I am talking not just a physician's office, but out of a hospital. So somebody gets discharged out of a hospital and then they go home, and, you know - again, in the hospital pharmacy, they are hooked up through HL-7, and then it goes out to the - you know, we have all talked about - then it would go out to NCPDP and go to a local pharmacy.
So this idea of whether a doctor can have one ID and it works throughout the process or it is one ID as long as they stay within their little network. Little not being a negative term. (Laughter). The network they have signed up to.
MR. GUINAN: It is possible that a physician, as he is practicing in a hospital, that hospital could be hooked up to one network, but his office is hooked up to a different network, and so that same physician could have two different ID's.
MR. REYNOLDS: Okay. That's -
MR. GUINAN: That is correct.
MR. REYNOLDS: Thank you.
MR. MEDVEDEFF: Mr. Reynolds, it has been our experience - This is Dave Medvedeff. We have run across that a number of times now where we have tried - we have actually assigned the doctor, through SureScripts, a SureScripts provider ID, but the doctor is using a medical manager as well in their office and has a ProxyMed ID, and that creates a tremendous amount of confusion in the retail pharmacy, because which doctor's name do you select off of the system. So they force him into one ID, and that does create some issues, and I know that SureScripts has been fairly diligent at trying to come up with a solution.
MR. REYNOLDS: And, again, I wasn't picking out specific vendors as an issue. I was talking about the flow in the process.
MR. SIMKO: And, ultimately, you are right, but, as David described, in today's world, we have that physician registered with two different software registrations because of that, because they have actually two different systems.
MR. REYNOLDS: But, again, when you get into PKI and you get into other things and you start talking about - we heard the discussion today that you have one number and everything else. I am hearing that the industry may have situations where they don't just have one number and they wouldn't have just one PKI and they wouldn't look like - That is all I was trying to clear up -
MR. GUINAN: Yes, it is a very real scenario.
MR. REYNOLDS: Okay. Thank you.
DR. COHN: Okay. Steve.
DR. STEINDEL: I have two questions, one for you, David, and the other in general.
When you were talking about your PKI system, PKI systems are associated with certificates. Where is your certificate?
MR. MEDVEDEFF: We actually have implemented a roaming certificate through Verisign. They call it their managed PKI. So the certificate is stored on a server, and, when the doctor logs in, it authenticates the doctor to the server -
DR. STEINDEL: Any cases where a prescription may be questioned, et cetera?
MR. GUINAN: We have been requested to provide records pursuant to a few Medicaid-fraud cases, and we have supplied the records, but I am not aware of what - you know - weight where it is given to them or not. So I guess the short answer is no, and, just speaking for ProxyMed, we haven't been involved directly in a litigation. I know that we have been requested to provide these type of records, and having them has been a very good thing for the prosecutors, but I don't know what weight they are given. Mike, do you know?
MR. SIMKO: We have been - as part of investigations on some practices for Medicaid fraud and other state medical societies about prescription abuse of controlled substances and that, and Medicaid fraud, in that regard, transaction logs that we have had through ProxyMed that we have asked that those be provided to prove that transmission did come from a particular physician's practice.
MR. GUINAN: No, but I don't think it's been tested yet to have a physician say, No, I didn't write that prescription, and then for us or someone like us to present, Well, it says here you did, and so I am not aware of anything like that.
MR. SIMKO: Yes, we don't know if that's been held up in any -
DR. COHN: Okay. Jeff and then Stan.
MR. BLAIR: David, do you have any statistics from Florida with respect to the incidence of fraud in prescribing? And let me kind of give you all of the layers of my question. In particular, if you do have any data on that, what portion of the fraud is - could be captured by better authentication and what portion of it could be then captured - authentication with PKI?
MR. MEDVEDEFF: I do have numbers as far as fraud in a general sense, in Florida Medicaid specifically. A grand jury convened late 2003 - in the winter of 2003 - and their rough estimate was that there is $1.5 billion in Florida Medicaid that is funding fraud and $300 million of a $200-billion budget was directly attributed to prescription-drug fraud. So $300 million out of $200 billion spent was prescription-drug fraud.
Now, the caveat there is that prescription-drug fraud is not necessarily patients writing themselves prescriptions or doctors abusing the system and writing patients prescriptions that are not appropriate. There are a number of layers - if you want to get into layers of fraud - such as doctors providing prescriptions that get fed into black-market wholesaling rings, and it is a very complicated, very lucrative businesses. You can imagine $300 million in just Florida.
As far as what portion of that could have been captured using authentication and maybe tighter security, you know, I had the one slide. It was one testimonial from one doctor who said he identified a patient who stole a prescription pad and wrote numbers of prescriptions. I am sure that story happens more than most doctors know.
And then the other response to that is, if technology is allowed to be planted in the community, you now have sentinels all around. So you have other providers, other prescribers that can see what else is going on with that patient, and maybe you can identify provider fraud, pharmacy fraud and patient-level fraud, because I think what is happening is more and more pharmacy fraud. No offense to our partners here, but pharmacy fraud is starting to be identified by doctors who are seeing patient prescription data come to them saying, I have never written a prescription for this patient. Why is this patient on these five medications? And when you start to drill down and you start to go through if there was a paper trail that maybe there is some fraud there.
So I don't know that I necessarily answered your question exact, but that is all the information I have.
DR. COHN: Okay. Stan, I think last question for this panel.
DR. HUFF: Just make sure I understand, in your use of certificates, the certificates were on your server.
MR. MEDVEDEFF: Posted by Verisign. They are not -
DR. HUFF: Not your server, that is correct. Verisign. And so you didn't have the same problems in maintaining the certificates that were described by Jack -
MR. MEDVEDEFF: Well, we went that route first.
DR. HUFF: Oh. Tell us about that. Tell us that story.
MR. MEDVEDEFF: He is very eloquent. It was the exact same scenario, and it was probably taken to another level when you are dealing with battery life on a PDA, and when you completely drain your battery and then you drain your backup battery, the PDA will do a hard reset when you turn on the PDA the next time, and it wipes out all the software on there, and you are basically starting from a blank operating system, and we had issues around loading new certificates and authentication, and he described everything that we had experienced, which is why we went out to the industry and said, What are the options available?
And another thing we liked about the roaming PKI - the managed PKI, as Verisign calls it - is it enables that provider to use a PKI certificate regardless of how they are entering the system, whether it is on their PDA.
We also have everything available on a website. So they can go in - user name and password, build a cert as they need it, use a certificate, and then, as soon as they log out, it flushes the certificate off of the hard drive and they can then log into their PDA again. So it creates some options and they don't have to have plug-ins and that kind of thing.
DR. HUFF: But, again, just - the potential Achilles' Heel of that is that, now, if you don't have a very strong authentication to the roving server, then you really haven't - I mean, you know it's coming from somebody in a secure package, but you are not sure who.
MR. MEDVEDEFF: The only thing you are doing with that is you are ensuring that the data was not corrupted when it was in that secure transmission.
DR. HUFF: Right.
MR. MEDVEDEFF: So it's in a secure pipe and the data inside the pipe is secure and nobody has hacked in and changed it.
DR. HUFF: Right.
And then my other question is just make sure - this is just sort of general education for anybody who wants to tell me. So is the typical - is that the typical scenario that we heard about faxing of prescriptions for controlled substances that is sort of the norm with - how are people handling, typically, now, controlled-substance prescriptions, and especially Schedule II?
MR. KILGO: Schedule II is no different. Still requires a signed hard copy, and, in our environment, the pharmacist leaves a message that they received a message for a controlled substance, called and receive a fax.
MR. GUINAN: And we don't allow the sending of Schedule II's at all on the network. For a while, we did the call-back methodology, but it wasn't clear that that is completely in line with what the DEA was looking for. So we don't - we just steer clear of it at the moment. So Schedule II's, we don't send over our network.
DR. COHN: What about III, IV's and V's?
MR. GUINAN: III's, IV's and V's, at the moment, we do, although this is an open question on whether or not that is - we should be or not, and our pharmacy partner and ourselves, we are all struggling with this, looking for some more direction.
DR. COHN: Steve, you have a final comment as we transition?
DR. STEINDEL: Just as a very quick comment. People have heard that CDC runs a PKI system, and we actually use the roaming certificate as well, for the exact same reasons that were outlined. You know, we had the same problems with computers crashing, et cetera.
DR. COHN: Want to thank you all for some very interesting testimony.
DR. COHN: Now, I believe we actually have NIST on the line calling in. We have Power Points we are going to put up, relatively high tech, and we'll just allow, I think, Maria, I guess, to get up there and get on it, but we want to thank the testifiers what has been some very interesting testimony.
Also, to warn people, we'll obviously take a break after the NIST presentation and discussion.
MR. POLK: Good afternoon. Are we on at this point?
DR. COHN: Yes, you are live. Can you hear us?
MR. POLK: Yes, I can. I just switched to holding the phone, so I have a little better sound, so I wasn't sure that you were waiting for me. My apologies for that.
DR. COHN: No -
MR. POLK: Good afternoon, and I am Tim Polk from NIST. I will actually be the only NIST speaker. Unfortunately, because of other duties involving FIPS 201(?), Curt Barker has asked me to cover the FIPS 201 topic for him, and I want to say I really appreciate your accommodating me by letting me call in, rather than appear in person. I would have liked to have been there, but we have - this has been a very - it is a very busy time this week, and I do appreciate your accommodating me in this manner.
I have submitted a presentation, an Introduction to Public Key Infrastructure, which is what I was understanding was needed as a background, although, I realize that the previous session spent a lot of time talking about PKI. So I will probably move through that fairly quickly.
I do not - unfortunately, I don't believe Curt sent a FIPS 201 presentation. Is that correct?
MS. FRIEDMAN: No, he didn't.
MR. POLK: Okay. I'm sorry about that. I think that he and I had some miscommunication, but I am prepared to cover FIPS 201.
I am also one of the authors of NIST 863, the authentication guidance document. So I would be happy to handle questions on any of those three issues as we move forward.
I think that probably the best thing to do, since you do have the slides on public key infrastructure, is I am going to move kind of quickly through them, and then I'll have sort of some free-form comments about the federal PKI and how it relates to this introductory material. Does that sound good?
MS. FRIEDMAN: Sounds good.
Tim, this is Maria Friedman, and thank you for sending the stuff in. I've got your slides up on the screen for the group to see, and there's also hard copies. So ready when you are.
MR. POLK: Great. Oh, I am hoping that this is - that this presentation is tailored somewhat towards your needs. I certainly, though, am happy to take questions afterwards if there are specific issues that I missed in all of this.
MS. FRIEDMAN: I think, particularly, the group had some questions - residual questions about the levels of authentication that were in your document and also on FIPS.
MR. POLK: Yes. Okay. Well, I kind of thought that, while you were looking for PKI, that, in the end, we would end up talking about 863. I am not terribly familiar with HIPAA, just enough to be rather dangerous, but I certainly can try to help interpret 863 and what it may mean for those of you who are trying to implement that.
MS. FRIEDMAN: Well, this particular discussion is - while this is the standards and securities subcommittee and we deal with HIPAA, this particular discussion is on standards as they relate to e-prescribing.
MR. POLK: Okay. Great. Good. I thought I had seen something about HIPAA in one of the earlier mails and I was worried about that. This is much better. Okay.
MS. FRIEDMAN: Okay. Sorry about the confusion.
MR. POLK: All right. Well, then, why don't I go ahead and go through the set of slides.
I guess a quick overview. When I do an introduction to PKI, there's really four basic topics that I like to be sure that I cover, and the first one is always, well, why, in fact, are we doing this?
The next one is what are these components? Because some of them you will have heard of, but maybe they are different names that get used at times to talk about PKI.
And, then, PKI architectures. You'll find that PKI's are somewhat like my son's tinker toys. You can assemble them in all sorts of interesting ways, and then they will have different properties.
And, then, finally, there is a specific topic called Path Validation in PKI that I just want to be sure people have a little introduction to and understand how this may impact your ability to build applications that use PKI.
Now, I've moved on to the slide, “Why PKI?” -
MS. FRIEDMAN: Um-hum.
MR. POLK: - and, as much as I have been doing this for more years than I care to admit, but PKI itself, while it is a lovely technical mechanism, it is really not the goal. The goal is to be able to get security services, and PKI is just one of many mechanisms that you can use to do this.
There are some nice things about PKI, and it is one of the reasons that cryptographers and a lot of security people are very fascinated - myself included - with PKI as being such a great mechanism, and one of them is that they are - that there's possibilities for scaling.
Public key infrastructure - if you have a half-a-dozen people that are working on an application, public key infrastructure is probably not something that you want to deal with, but if you are trying to roll out an application that is going to have a very large and perhaps very diverse community of users, PKI may very well be a good choice.
So one of the other things that is nice about PKI, on the next slide, is that you can do pretty much anything, in terms of provisioning security with PKI.
The one thing you really don't do with PKI is you don't address denial of service, but PKI - a good PKI should let you authenticate who your users are, establish confidentiality. You should be able to use those keys to set up a secure pipe. You should be able to protect the integrity of your data in transit, and you actually have at least the technical mechanisms in place to be able to say, after the fact, who did what. That is the technical non-repudiation.
There's lots of ways to get around some of the - I say technical non-repudiation, because while the mechanism will show what keys were used, there's lots of ways that users, by not following the rules, can disclose information or let someone else use it, and so you may still have to go to court to discuss who really did what, but the keys are pretty much irrefutable.
Now, on to the next slide. Most people are familiar with cryptography, but they usually are thinking of secret-key cryptography, which is where if Bob and Alice want to exchange information, they both need to have the same key. Cryptography, in one form or another, has been used since the time of Caesar, with the secret keys.
There's a lot of - when you hear people talk about the DEZ(?) or the triple DEZ or the advanced encryption standard or AES that NIST has done, all of those are what we call secret-key cryptography, and there is one sort of Achilles' Heel for secret-key cryptography and that is that Bob and Alice have to share a key. They have to share a secret, and as soon as more than one person knows the secret, it is really not much of a secret. So it undermines an awful lot of things, and some of those services that we were talking about before, like non-repudiation, very difficult to do with secret-key cryptography.
Now, in the early ‘70s, a new kind of cryptography was invented called Public Key Cryptography, and in Public Key Cryptography Bob and Alice actually have two different keys that are mathematically related, only one of which needs to be kept a secret. There's a lot of neat things about this, which is that you can use the same set of keys for multiple users. Everyone can share the one key that is public, and only the user that needs to hold the secret has to keep the one secret, and it really is secret, because only one person has to have it.
There are a number of issues with this. It is a much slower type of cryptography than secret key, but it is very - people are very interested in doing this, because it solves that major problem of Bob and Alice having to have the same key with secret-key cryptography.
But the biggest weakness - the keys are all so much longer. You'll hear people discussing how large key sizes should be, and sometimes people will get mixed up with this. A secret-key algorithm like AES, which has a 128-bit key, is as strong as a public-key algorithm, a lot of times, that might have a much larger key. So there are issues that have to do with the sizes of keys and being able to transmit information back and forth with public key, but the really big problem with public key is being able to figure out who is the person that a public key should be associated with.
So we can move to the Choosing Cryptographic Tools slide.
There really is no one-size fits all solution when it comes to cryptography. You really need to be able to combine these different kinds to build any kind of an efficient system.
If you have a document that you are wanting to encrypt, so - you know, a large Microsoft Word document or a PDF document - you would never want to use public-key cryptography. It is very, very slow to encrypt that kind of data, but secret-key cryptography works very well, but, on the other hand, if you want to know who sent you that Microsoft Word document, what you want to do is something called a digital signature, which is something you do with public keys.
If you wanted to find a way to be able to encrypt that document and then get that key passed to another person, you use public key to transmit short pieces of highly-secret information, where secret key is good for bulk encryption.
So you can see there is a need to be able to combine these tools in almost any system. In large systems, you really want to be able to build them using the best of both of these kinds of cryptographic mechanisms.
So, as I said, the one big problem with public key is - public-key encryption or public-key cryptography is how do you get the key that is not secret - how do you know that you can trust it for any particular user, and that is actually what PKI is all about is solving the problem of whose public key is it and what is it good for.
So if we could move to the one that says Credit Card.
There is an analogy that I like to use that it really holds pretty well for public-key certificates and for PKI. Everybody is familiar with a credit card. It has some information on it. It is basically that credit-card number and the name, things that are in there on the mag stripe. It's got an expiration date. Everything you need to know to be able to find out if you can - everything you need to know - What is the number? Who is it associated with? It is all on that credit card, and, to the first order of magnitude, you trust it, because it says it is from - it says it is a Visa card or it says it is a Master card.
Well, a digital public-key certificate is sort of like that. It is the way that instead of the credit-card number, you get my public key and you can determine that it is associated with Tim Polk. So it is a little bit different in that it is not all that hard to forge a credit card, and, actually, it is fairly difficult if you follow the rules to forge a public-key certificate.
If you could move to the slide that says, Using Public Key Certificates.
The way you would use a public-key certificate, if Bob has signed a document - say an email - and sent it off to Alice, Alice needs to find Bob's public-key certificate, and she uses the key in that certificate to be able to verify the signature on the document sent to her. If she can do that, well, that is the first step.
The second step is she has to check and make sure that she can trust this certificate. You do all of this through digital signatures. Basically, she has to find two digital signatures in this picture and show that both of these digital signatures verify against the public key, one in the certificate and one that she already had, and she builds sort of a chain that says, Well, I can trust the email from Bob, because I can trust his certificate, and each of these signatures verify.
So this is conceptually how you use public-key certificates to establish authentication services, to check a digital signature, find out what the origin of a message is.
So there is one other - there's really two data objects for public-key infrastructure. There's the certificate, and then there is something called a CRL.
CRL's are one of the ways that we do what we call status checking. Just like if I am issued a credit card, if I quit paying, even though the credit card hasn't expired, the credit card is no good anymore. Public-key certificates may be revoked, too. Maybe I have left the company. Maybe I lost the crypto module or it was stolen from me. One way or another, there may be reasons that even though Bob has a certificate that Bob's certificate isn't trustworthy anymore.
If you think about credit cards again, there are two mechanisms that I know of for handling credit-card revocation. Years ago, when I used to work retail, we had a paper booklet that I would flip through to look for cards that had been stolen. We called it the Hot List.
The second way, which is what people tend to do now, is they swipe your card through a machine. It contacts the credit-card company or the credit-card issuer and finds out whether or not I am under my credit limit and whether or not they can handle the transaction.
The Hot List, the paper booklet for hot cards, is a lot like what we call a CRL. It is - once again, it is like a certificate and then it's a digitally-signed object and you can figure out whether or not you trust the signature on the CRL, and then if my card number, or, in this case, my certificate number, is listed, you know it is not a good certificate anymore.
There are some protocols and some systems that can be used to do status checking on line, where you contact a trusted server and you find out whether or not that certificate is good.
So both of those analogies have - both of them have a corollary in PKI.
So if I could move into the slide that says, Certification Authority, I am not going to go through - just in the interest of time, I am not going through all the different components, but I would like to talk about the three most important components for a PKI.
The key component of a PKI is a certification authority. It is the system that digitally signs certificates. It is the system that is making an assertion that this is Bob's public key. That is a trusted system that - but you may only have one system for a very large organization. You don't need to have lots of them, because they scale rather nicely.
You usually put it inside a security facility. You have lots of very tight controls on how it is operated. Users don't come in and ever touch the certification authority. That is not that kind of a machine.
The next component is the one that deals with users, for user enrollment and registration, the registration authority. This system is the one that does the identity proofing and determines whether or not - it is the system that decides that Bob should have a certificate and that Bob is the correct name to put into the certificate.
This is a system that is trusted, but only by the CA. Really, it only exists to do operationally one operational control of does someone need to get a certificate, is this the right person, does that certificate need to be revoked. They handle passing that kind of information to the CA.
And, then, there is a component that is actually not a trusted component. The repository is usually an LDAP directory, but a lot of times now people do it with web servers, but it is just basically a database that is online. You send a query to it - I am looking for a certificate for Bob - and you get an answer back. I am looking for a CRL issued by a particular CA, and you get an answer back.
Because all the data in PKI is digitally signed, usually, you just don't really have to protect a repository other than making sure - you usually - you are protected in terms of the integrity of the information that is sitting on it, but you don't have to worry about who accesses the information and you don't - and, in fact, if there is ever a problem of data being replaced by an attacker, users will be able to figure this out, because the digital signatures will no longer work. If data is replaced or modified, this will be self evident to the users of your PKI.
Now, PKI architectures. There are five architectures I would like to mention. I'll try to go through them pretty quickly so that we have time to move on to some other issues, but the simplest way to do a PKI is to build - is to have one really big CA. All the users that are going to use your application all get their certificates from the same CA.
For large applications, this may - and ones with particular security sensitivities, this is something that you can do and justify, although you are not probably taking the full advantage of the whole world of PKI, but, then again, your application doesn't demand it.
It is easy, in fact, to get a PKI to work and to work very well with a single CA model, and if you really have control of the application and the user community, this is a great way to do things.
More commonly, perhaps the most common PKI that an organization or an enterprise - most common architecture is the hierarchical PKI, which is on the next slide.
In this, you have a superior subordinate relationship. Usually, what you do is the superior CA out of the PKI we would call the root. It's the one at the top of the screen, and subordinate CA's would then issue certificates to users. You could make this more complicated by having CA's that have more CA's beneath them, but this is the basics of hierarchical PKI, and you can build very large PKI's using this model.
For example, the Department of Defense uses this model and they have three-million users, I believe, at the last count, in their PKI.
The next architecture is what is called a Mesh, and in a mesh you have a number of CA's that really are basically all peers. None is the most important or the least important. There's just several CA's, but each have a community of users that they issue certificates to, and these CA's have to have some kind of trust relationships between them.
Now, all of this is normally hidden from users, because what you are most familiar with, if you have ever kind of looked under the covers of your browser, the PKI that you really have that you would use at home or that you are most likely to use for things, like when you are doing secure web browsing, is based on the trust list, and the idea here is that there are many, many small PKI's. They may be a little mesh of three or four CA's. They could be a hierarchy. It could be a single CA, but rather than having to list all of the CA's - it is just a list of different starting points for you to be able to find a way to trust the certificate, and that is what is commonly done in the browsers.
These days, browsers ship with a list of about 130 CA's that you are expected to trust or that you may wish to trust.
Now, you can think, if we are up to - we haven't been doing PKI that long, and we are already up to 130 certificates in the browser, at some point, we need to move beyond these small enterprise PKI's of three or four CA's and start to tie them altogether into a - hopefully, someday - a global PKI.
Now, we have been working in the federal government for a while to try and construct such a PKI that covers all of the U.S. federal government, and the tack that we have been taking, we invented something called a Bridge CA, and the idea is that we are going to take a whole bunch of different PKI's that were built for their own reasons, tie them altogether, and, now, that CA that you deployed to support one particular application, now, it will let you do other applications with other users, and that is the goal of the Bridge CA.
If we could flip to the second of the Bridge CA slides, the Bridge CA example, you can see that it can quickly - taking a CA and dropping it in between, suddenly, we have a much larger PKI. Imagine that instead of two PKI's like that, there are nine, as there are, I believe, currently in the federal PKI, and you can see that, very quickly, the size and the number of users that might be available to do an application with can become very large.
However, I glossed over something that is a very key point here. One of the reasons that much larger PKI's have not been created up until this time is what we call the Path Development, the Path Discovery and Validation Problem.
If you recall, at the very beginning, Alice had - to find out if she could trust Bob's certificate, Alice needed to use a key that she had stored on her system to validate a certificate for Bob, and then she used the key from that certificate to validate Bob's message.
Well, that works fine when Alice and Bob are just both working from the same CA. Imagine that Alice wants to validate a message from Gwen all the way on the right hand side of the screen. The way that she actually has to do this is that she needs to use the key to verify one certificate and then another and then another, until she finally gets to Gwen's certificate - each of those certificates actually representing a relationship between two CA's - until she finally gets to Gwen's certificate, and she has Gwen's public key, and then she can actually validate a message that she got from Gwen.
Now, that is the last slide that I have on PKI, Pass Validation. Of course, I did Bob, which wouldn't have - the point here is, though, that there can be this cascade of certificates. You need to go through this whole path, because PKI is sort of a derived trust model. I trust one CA. It trusts another CA. That CA issued a credential to Gwen. Well, at that point, you are able to say, I can trust the message from Gwen.
So this all sounds fairly complicated, and it can be difficult to retrieve the right certificates, because the standards are really not as solidly in place in that area as they should be.
Validating that path of certificates is very straightforward. We have good standards on how to do that and determine whether or not a particular sequence of certificates is any good, but the problem of finding them is still a challenge, and that is actually the biggest challenge we face in the federal PKI today is that while we are constructing a very strong federal PKI, a lot of the commercial off-the-shelf software is still struggling to make proper use of that.
So that is the - everything I had on PKI.
My comments that I would say is that in the federal PKI that is really growing, and we have a lot of momentum and a lot more agencies are joining, but we are still struggling with some of the software functionality problems in that a lot of times, people who have implemented PKI in applications have implemented it with one of the much simpler PKI architectures in mind, something like a small hierarchy or even just a single CA, and when you move into an architecture like the federal PKI has now deployed, those implementations do not necessarily work.
So should I take comments, questions about PKI at this point or would you like me to give an overview of FIPS 201?
MR. BLAIR: Could we go into the authentication levels?
DR. COHN: Yes. Yes, we would like for you to continue on, because I think - this stuff, I think, you have told us so far, I think we are pretty familiar with, but obviously like to hear the other part.
MR. POLK: I was afraid of that. Okay.
DR. COHN: We would like to understand this other piece.
MR. POLK: Okay. FIPS 201. I am sorry that you don't have slides. I will send you a set that can be distributed later, if that is useful.
MS. FRIEDMAN: Yes, thank you, Tim. This is Maria. Send them to me.
MR. POLK: I will do that.
Let me go over FIPS 201 real quickly. I think most people have probably heard that this project is ongoing.
Last August, the President signed Homeland Security Presidential Directive No. 12, Policy for a Common Identification Standard for Federal Employees and Contractors.
The general objectives of this standard were that we be able to have reliable identification verification on a government-wide basis for government employees and contractors. This needed to be interoperable, and it needed to be strong enough that we had a real basis for reciprocity. We felt that agencies were not comfortable accepting credentials issued by other agencies. They felt uncertain of what standards had been implemented in doing this.
MS. FRIEDMAN: Hey, Tim, this is Maria.
MR. POLK: So -
MS. FRIEDMAN: Hey, Tim, can I interrupt you for just a second? I think - you know, we are - in the interest of time, I think what we are really interested in is your other document.
MR. POLK: 863?
MS. FRIEDMAN: Yes.
MR. BLAIR: The authentication levels.
MS. FRIEDMAN: The authentication levels.
MR. POLK: Yes.
MS. FRIEDMAN: One of the things we had discussion on last time was the authentication levels, and our cochair, Jeff Blair, had some - Jeff, you want to kick off this discussion real quick with him and -
MR. BLAIR: Oh, sure. Sure.
MS. FRIEDMAN: - tee this issue up?
MR. BLAIR: Yes. We are really hoping that you may be able to help us understand what would be the appropriate authentication levels that would relate to e-prescribing.
MR. POLK: Excuse me, would relate what?
MS. FRIEDMAN: To electronic prescribing.
MR. BLAIR: To electronic prescribing.
MR. POLK: Okay.
MS. FRIEDMAN: We looked at - just to back you up a little bit, the document was intended for a much wider and deeper use -
MR. POLK: Absolutely.
MS. FRIEDMAN: - and so what we are trying to do here is figure out if any of those levels actually can be related to electronic prescribing, which is the charge of this group, electronic prescribing for the Medicare Part D benefit. So it is a federal program. So we gotta take this stuff into account.
MR. POLK: Absolutely. Okay. Well, the place that we really need to start is not in this document. It is OMB Memorandum 0404.
MS. FRIEDMAN: Yes, OMB was here and they had a similar kind of hierarchical set of levels and we weren't sure how theirs fit together with yours.
MR. POLK: Okay. The set of four levels that are specified in 863 and the set of 400 levels for OMB 0404 are exactly the same. The document was designed to align precisely with Memorandum 0404. In fact, we wrote that document because OMB came to us and said, We have written this memo. We need NIST to write the technical guidance on how to implement it.
Now, let me say, now that I have said that, 863 applies to a very specific environment. The assumptions of NIST 863 are that we are communicating over an open network, that the person that we are attempting to authenticate and the server that is attempting to authenticate their identity are not co-located, and we don't make any assumptions about their being a secure network in between.
So the first step would be to say, if that is the environment that your electronic prescribing network works in and - then we would need to look at 04 - the OMB memorandum and determine where you believe you fall on that list of four levels. That would be our first step.
If you feel that you have a significantly different environment, but say you own the network and - you know, so no information ever goes across the internet or the system it is authenticating the identity, you are there physically present at that server, then you would have - then 863 might, in fact, be overkill for your environment.
What 863 prescribes for that level - prescribes is probably the wrong word here, but what it specifies for that OMB level would be stronger, perhaps, than you needed because your environment had additional protections that we could not take into account.
DR. STEINDEL: What if you have a virtual private network that is running over the open internet?
MR. POLK: If you have a virtual private network, then it depends on - if the virtual private network provides - you may improve things because the virtual private network may, in fact, preclude some of the man-in-the-middle attacks and that sort of thing that we worry about in 863.
However, that would also be that you would have to be making an assumption that all of the systems on your virtual private network are then trusted. If you are worried about internal attacks from other people who are, perhaps, permitted to be on the virtual private network, but that are - that you still have to worry about them mounting an attack on some other user, then you would not be able to claim that the virtual private network overtook - you know - over - provided those extra controls. So it depends on your community. Okay. You are not going over the internet, but are these all fully-trusted people is - you have to decide what your threats are.
Our assumption is that other people that are on the network are, in fact, a threat. As long as that is still true, having a virtual private network is probably not going to change your situation appreciably.
MS. FRIEDMAN: What if you have secure private networks and you have a whole system of contracts and trading-partner agreements in place to help not only make it all work on a business level, but also make it work on a trust level? Is that what you are looking for as well? I mean, those kind of things that add to the trust levels, I guess, is -
MR. POLK: Sure. I mean, you can always take those things into account. You now have a virtual private network. You have some other set of agreements that go with this that compensate for some of those - they compensate for some of the threats that we list in 863. We would not claim that you shouldn't take those into account. I think you should, but it is still the - you have to decide how much faith you really have in those mechanisms, and you have to recognize that those are a risk that you are accepting that, you know, how much are you - are you willing to rely on the trading-party agreement to say I am not worried about an insider attack, so I don't have to worry about the man-in-the-middle attack, then you can do that, but you have to consider whether or not you believe you can accept that risk.
MS. FRIEDMAN: And just let me - this is Maria again. Let me clarify one thing I thought you said. Where you guys were really coming from in designing these risk levels was the insider attack, the man-in-the-middle attack. Did I hear that correctly?
MR. POLK: Well, there are a list of things that we worry about. At the highest end, we worry about things like session highjacking, where Alice is connected to a server and she is authenticated, and then someone else is able to highjack the session and continue to communicate as if she was Alice, even though someone else has stepped in. That is something we worry about only at Level 4.
At Level 3, we had decided that to meet the OMB requirements, you had to worry about a man-in-the-middle attack. You had to worry about verifier impersonation.
At Level 2, we worry about things like eavesdroppers. I don't think you have issues with eavesdroppers if you have a virtual private network, unless you have decided that even within your virtual private network eavesdropping is something that you have to worry about from your community of users.
You might reasonably be able to say, I don't worry about eavesdropping. I have the virtual private network, but you still might have to worry, for example, about the man-in-the-middle attack or maybe about session highjacking. We would have to look at the actual mechanism that you are using.
But we came through and set up a table. There is a Table No. 3 in our document, on page 40, that says what the required protections are at each of the four levels.
If I was looking at a network like yours where I think I could claim it is appreciably different than the authors were - you were not getting any extra points for having a VPN in the way we set up 863. I think you would have to come back and look at the mechanism and say, Does the VPN protect me against eavesdropper attacks?
MR. BLAIR: Can I -
MR. POLK: - protect against? Well it protects against people -
MR. BLAIR: Can I interject?
MR. POLK: - who are not part of the virtual private network. Then you might go through different levels, and you may be able to say, I can check off the boxes that are required at my level to meet the OMB guidance. So even though I am not using one of the NIST-prescribed mechanisms, my environment gives me all of those check boxes, and that is what I would key on if I was trying to demonstrate that my architecture gave me the right requirements.
MS. FRIEDMAN: I think our co-chair had a question. He is going to jump in here.
MR. BLAIR: Let me try to ask a question that I think might be representative of the question that many of us may have.
The area where we need help is trying to determine whether typical environment for e-prescribing should be a Level 1, Level 2, Level 3, Level 4, and if it is going over a private network, which seems to be that most of the e-prescribing environments are, to commercial and retail pharmacies, the major concern, I think, that many of us have is trying to validate that the prescriber is who they say they are.
MR. POLK: Right. Okay.
MR. BLAIR: And so would that - where does that bring us in terms of Level 1, 2, 3 or 4?
MR. POLK: Unfortunately, 2, 3 or 4 does not have to do with what - what you have said is that you have one particular threat out of the threats that we worried about. Really, the remaining threat that you are worried about is whether or not it is really Bob or Alice.
MR. BLAIR: Yes, I won't say that we have only one threat. I'll just simply say that is the primary threat.
MR. POLK: You know what, I feel like I am overstating that.
MR. BLAIR: Yes, that is the primary threat.
MR. POLK: That is the primary threat. So - but the problem is that OMB 0404 is based on what is the risk for your data if it is disclosed, if it is compromised, and so it has to do - I mean, so, for example, even though you only have one aspect you need to worry about, which is what is the identity of the person - authenticating the identity of the person doing the transaction, you still could end up at Level 3 or 4 based on the importance of your data, and I think that people would make a claim that you are probably at Level 3 or 4, because if - for example, I personally am allergic to penicillin. If someone could change the prescription as it was being sent, that would be - that could be very dangerous for me in terms of if I am being prescribed an antibiotic.
On the other hand, there are also strong privacy-related things. If you are prescribing someone a drug that is primarily used to combat HIV, there are privacy issues that they would probably say rank up fairly high as well. So I don't think that we can look at your environment and claim that that reduces your OMB authentication level. We would do the reverse. We gotta look at your data and say what the OMB level is, and then we say, But your environment addresses four out of the six check boxes and we can address the last one in this manner.
DR. COHN: Tim, just ask a question. I mean, it sounds to me like we are both - all sort of looking at the OMB document and we are sort of reflecting that some of this sounds a lot like the HIPAA security regulation in the sense that what you are talking about - and, actually, what you are saying is being very useful, because you are sort of a) talking about this issue of being on the wide-open internet, but you are sort of speaking of - you know, this is where we would like to get, but there are a range of mitigating or compensating factors that need to be taken care of - taken into account as one makes a final determination on exactly what one is doing about this one. That is sort of what you are saying.
MR. POLK: Yes. What I am saying is that the technical requirements to meet your - whatever - the OMB authentication level, may, in fact, be reduced by your environment because it is not something we thought about with 863.
I would also say that I suspect that you are exactly right that the sort of way they think about your requirements for HIPAA are probably closely related to the same way that they have laid out the requirements here. It has to do with what are the consequences of compromise or modification of data when you set those levels.
So when you determine your OMB level, it has a lot to do with - it has more to do with what are the consequences, basically, under HIPAA? What are the same kind of consequences that you have to worry about if this data gets changed or if the data gets disclosed when it should have been confidential? So you have to think about that, and then you get to factor in all of the mechanisms that you use, including things like your VPN's and your trading agreements. You can factor all of those in to am I really meeting that level.
DR. COHN: Very appreciative of your conversation here. I am actually also reminded that - I am hoping in February we are going to hear back from NCPDP and the industry around what are, effectively, I think, we are describing as best practices around some of this, which, I think, in your context are now sort of compensating or mitigating factors around all of this.
MR. POLK: Well, yes, I mean, I wouldn't - normally, I wouldn't say that they are mitigating factors, because they are all technical controls that help you achieve your requirements. I just keep saying that they are sort of mitigating factors because if you looked at 863 in a vacuum and said, Oh, we have to do all of these things to meet either Level 3 or Level 4, that that - you really don't have to do all of those things because you have all of these other technical controls in place that we couldn't assume.
For 863, our model was much more my mother contacting Social Security over the internet. That was the kind of environment that we had to assume - It is sort of the worst case, and it is the one that we had to assume that we were addressing with 863, but, again, that isn't the world you live in, and so if you did the same controls that we would have prescribed for that kind of environment, you probably will have overkill.
DR. COHN: Okay. Do other people have questions or comments?
Yes, this is being very helpful.
Now, do you have any - we are really sort of asking our questions at this point. We really appreciate it.
Did you have any other perspectives on this particular piece that you want to share with us? Because I think you are sort of answering many of our questions here.
MR. POLK: I think that what I would say - you know, this is the sort of thing that has always kind of worried us with 863. It has been very difficult - It was a pretty difficult document to write, and we had to make a lot of assumptions in the beginning, and I would really encourage you to take the approach of going through and saying, Here are the controls that we already have, and what this adds to the environment that NIST had considered were these features, because computer security should always be cost effective. It should always be in line with your needs, and we certainly don't want you to go beyond that just because when you pull the document off the shelf, don't just flip to that level.
The one other piece - the piece that I think you will find perhaps the most difficult to meet in your environment will, in fact, be the identity-proofing sections, because one thing that - we have been talking all about the mechanical mechanisms, but if, in fact, I issue a certificate and I put Bob's name on it and I gave it to Alice in the first place, you really don't know who that person is. The very first step - the identity-proofing step is key to any kind of authentication mechanism. Whether it is passwords or PKI, knowing who that person is when you issue them the original credential is a key step.
You have an advantage in that you are working with people who know their - I mean, if it's - you are sort of working with people that know their customer or who know their internal structure, I think, a lot of times, but I would say that that is probably going to be the trickiest piece, because I think you have enough technical mechanisms in place to help you come up with something cost effective, but that that is the place that I would worry and go back and look.
DR. COHN: Well, that is very well said. I think we all are well aware that PKI doesn't really solve that problem -
MR. POLK: Right.
DR. COHN: - and it is really that main input, and we have talked about biometrics and smartcards and everything else, which I think are the pieces of technology that you are referencing -
MR. POLK: Um-hum.
DR. COHN: - in terms of all of that, but I think it does give us some thought. Though, of course, some of that may be as simple as - you know - really just identifying that that person is who they say they are and getting all the proof, the notarization, et cetera, et cetera.
Well, I don't have any more - I mean -
MR. POLK: Getting those key steps - those initial steps right is very tricky, and, of course, is the - it is the piece where - it is the foundation for everything else. So it is the one where I think most systems, no matter how good the technical mechanism is, if they are going to fail, that is where they fail.
DR. COHN: Okay. Well, Tim, thank you very much. I think you have addressed our questions and more, so we really appreciate it.
MR. POLK: Well, I'm glad to hear that. I was a little worried. I'm afraid that the original presentation wasn't quite on the mark, but I am glad to hear that I have at least made some progress here.
DR. COHN: Yes.
MR. POLK: And I do appreciate your letting me work remotely. I know that doesn't usually make things quite as efficient, but it was very important for us and we do appreciate it.
MS. FRIEDMAN: Thanks, Tim - it's Maria - and thank Joan also for me.
MR. POLK: I will do so.
DR. COHN: Okay. And why don't we give everybody a well-deserved break, say, 15 minutes -
MS. FRIEDMAN: Okay. You're done. Thanks.
DR. COHN: - and we'll get together at 20 to four.
MR. POLK: Okay. Thank you all. Goodbye.
(Break)
DR. COHN: Okay. Our next presentation or set of discussions, really, it really relates to ASTM standards, and we are obviously happy to have Alan Zuckerman and Lori Forquet - hopefully, I have said your last name - what? Oh, and Dan Smith. Okay. Thank you. Third one here - joining us for the discussion.
Now, I think before we start, Lori, are you going first?
MS. FORQUET: I will start first, and I will cue in the folks. I'll give you an overview of what we are covering.
DR. COHN: Okay. Great.
Okay. I know Jeff has a comment he needs to make before you jump in.
MR. BLAIR: Yes. I will be recusing myself from any votes or decisions related to ASTM, and the reason is because my employer is chair of ASTM, but I wanted to go on record that no case and no time and in no way has my employer, nor has ASTM, ever made any attempts to influence my decisions or the role that I play as vice chair of ASTM, at this time, or ever in the past. So that should be on the record that there's been never any attempt to influence my decision.
Now, in interest of full disclosure, I also want it to be on the record that there's been times when we have had folks who are testifying to us where they have either asked for guidance on how they prepare their testimony or I have volunteered to assist them so that they understand the questions, the issues, the focus of the committee, and I volunteered to do that to provide some guidance as ASTM prepared its testimony. That was not because I was asked. That something I volunteered to try to assist them and to assist us as I have done with other testifiers in order to make their testimony more relevant.
Thank you.
DR. COHN: Lori, why don't we let you lead off, please?
MS. FORQUET: Is the mike on? Because I know I have a hard time speaking up. So -
DR. COHN: Doesn't sound like it's on.
MS. FORQUET: It doesn't sound like it. Let me try this one.
DR. COHN: Yes.
MS. FORQUET: This one is working. Okay. Make sure I don't have a problem.
Okay. Lori Forquet. I would like to thank you, once again, for having us back here to discuss, in a little more detail, some of the ASTM security standards that would be applicable for the e-prescribing discussions that we have heard today and, actually, in the December hearings as well.
I did describe my positions prior, but the ones I would like to mention once again, Chair of E 3120, Health Information Security; and Vice Convener of ISO TC 215, Health Informatics, Working Group 4 on Security; and I am a member of IHEIT Infrastructure Committee, and I only mention that because I will be discussing some of those activities throughout the presentation.
Just an overview of what we'll cover today: ASTM standards for health information security and privacy. Dan Smith will give an overview of ASTM, and then I will describe a little bit of ISO TC 215 activities that have been conducted through ASTM. ASTM involvement in IHE, and then we'll move on to just a little overview of the other possible e-prescribing information workflow models. ASTM framework starting to go through the ASTM standards that we referenced last time and believe to be applicable in this space. ASTM framework, E 20-85. ASTM Internet and Intranet Security, E 20-86. ASTM Security Standards for Electronic Signature, including E 17-62, which is electronic authentication of health information; E 20-84, which is authentication of health information using digital signatures; and E 21-22, which I will actually be discussing in the context of the ISO uptake of that standard.
I'll describe, just briefly, some of the industry uptake of the ASTM standards, and that will be followed by Dr. Zuckerman, who will demonstrate a product which has had some standards uptake.
Dan.
MR. SMITH: Good afternoon and thank you.
I'll just have two slides that will provide you a little bit of an overview of ASTM, and I know - I don't want to take up more than a minute here.
ASTM is one of the largest standards organizations in the world, and we are different from most standards organizations in that we don't specialize in any one industry. ASTM writes standards in virtually every industry. We have a membership base of approximately 30,000, and we have about 11,000 standards, again, that cover almost every industry you can think of.
ASTM is ANCI accredited, meaning that our standards development process has met the ANCI requirements, and we have had a very strong relationship with many federal agencies, evidenced by several thousand ASTM standards that are referenced and used in the Code of Federal Regulations.
Specifically, ASTM E 31 on Healthcare Informatics is responsible and has jurisdiction of the standards that Lori will be introducing and covering today.
E 31 was formed in 1970, and, today, they have over 30 standards.
The committee is comprised of approximately 320 or so members that basically cover or basically have membership of all the major stakeholder groups in the healthcare industry.
So unless there's any questions about ASTM, I'll turn it back over to Lori.
MS. FORQUET: Thank you, Dan.
And to lead off from that, ASTM E 31-20 addresses the health informatics security and privacy standards. These address areas of confidentiality, authentication, integrity, non-repudiation, access control, audit logging, privilege management, identity management, secure archive, availability, including emergency access issues, reliability of data, authorization, accountability, amendments to health information.
The privacy-standards space tends to address the issues of consent, in the international space, sudanimization(?), disclosure, trust agreements, training of individuals with access to health information, and things such as anonymous care.
The ASTM security-and-privacy standards that I will not be highlighting today - I did want to provide you a list of the other security-and-privacy standards, should it come up that you are interested in pursuing any of the others in more detail. They have to do with unique health identifiers, active work on defining this security for the continuity-of-care record, which you see a lot of uptake in the health-information-system-vendors industry for communication of health information and potentially even communication of e-prescribing information.
The 1869 Standard Guide for Confidentiality Privacy Access, state-of-security principles for health information, including computer-based records. 1985, which is a standard guide for user authentication and authorization. 1986, which is a standard guide for information-access privileges to health information. E 21-47, which is a standard specification for audit and disclosure logs for use in health-information systems, and we also have an active work item on privilege-management infrastructure.
Those that I will be covering today are ASTM E 20-86, which is a standard guide for internet and intranet healthcare security; E 20-85, which is a standard guide on security framework for healthcare information; E 17-62, which is a standard guide for electronic authentication of healthcare information; and E 20-84, which is a standard specification for authentication of healthcare information using digital signatures.
There is also the E 22-12, which is the standard practice for healthcare certificate policy.
ASTM involvement in ISO health informatic security standards, ASTM was one of the lead organizations involved in establishing the ISO Technical Committee 215 on Health Informatics several years back, and I want to - I believe it was 1998.
ASTM managed the U.S. Technical Advisory Group, provided the TC Secretary, during the startup years of that initiative, and ASTM has contributed, completed an in-progress standards work as a U.S. contribution to the development of the International Health Informatics Security Standards.
The ISO TC 215 Security Standards, we have a new work. I had a proposal on sudanimization. We have health informatics guidelines on data protection to facilitate trans-border flows of personal health information, a technical report on trusted end-to-end information flows, active work on security management using International Standard 17799 for health care, and directory standard, TS 21091, for directory services for security, communications and identifications of professionals and patients.
Integrating the Healthcare Enterprise, I believe you would be familiar with it, but IHE is a multi-year initiative that creates a framework for passing vital health information seamlessly from application to application, system to system, setting to setting across the entire healthcare enterprise. This is a vendor forum, whereby specific implementation profiles for the uptake of underlying standards are defined, tested and demonstrated by the industry vendors, and this organization is sponsored by HIMS(?).
The IT Infrastructure Committee is working on a proposed profile for digital signatures and attestation and authorization where the implementation profiles to electronic signature standards I am describing today will be addressed. The work is expected to be addressed this year for demonstrations early in 2006.
We have seen a lot in the information flow from - going from the prescribers of the drugs that were in question from hospitals or community physicians through the value-added networks and off to the pharmacy, but we have not really heard about the other potential pathways that e-prescribing might be able to take. Perhaps unlikely, but technically feasible, email, EDI, whether it be via script, HL-7 or the continuity-of-care record, and those transactions could go from the prescriber directly to a pharmacy, depending on the networking and the level of integrations within that community.
There is also movement toward patient portable health records on smartcards, and so that prescription could feasibly be a continuity-of-care record, for instance, that is put on the patient's smartcard and carried by the patient to the pharmacy.
There is also the other integration factor that we need to consider, which is for the physician and the clinician. It is part of the longitudinal health record. It is part of the patient record and part of their day-to-day clinical activities.
The ASTM E 20-85, the scope of that document, as a framework for healthcare information, is to provide the framework for the protection of the healthcare information, addresses the storage, transmission of health information. It is designed to accommodate very large - whether it be national or international - distributed user bases. It is intended to be spread across many organizations, and it - in light of that - recommends the use of certain scalable technologies over others, but note that it recommends and does not prescribe.
The specific existing standards are identified which accommodate many cases, including those from ISO, ITU, IETF, and our discussions last month, there was some question as to what underlying security standards might be utilized in looking at some of the security behind the network security that has been described here, and so this guide would be suitable for taking a look at whatever the architecture is and looking at the underlying engineering standards and recommending the appropriate use of those standards, where possible.
This document also discusses the high-level requirements for healthcare. It details the requirements in other documents. So this is only addressing the high-level requirements. Details would be spelled out in other documents, such as the E 17-62 that we'll be discussing.
Where the healthcare-specific requirements may be met by extending an existing standard, we would also prepare a new document, and that would be the case with E 20-84 that I'll discuss.
E-threats. The 20-85 document provides a security overview of the potential threats that the security services may detect or prevent attacks from. This would include Masquerade, which is successfully pretending to be another entity. This would include impersonation of users or system components. It would include falsely claiming origination or acknowledging the receipt of a message or a transaction. An example of this might be an individual masquerading as a physician in order to attempt to write a prescription for a narcotic or other controlled substance.
Other threats would be the potential for modification of information, modifying a message or data content, destruction of messages or data. An example of this threat would be an attempt to change the prescription quantity or dose in an attempt to divert drugs.
Message sequencing. Orders of message would be altered, and this would include replay, preplay, delay, reordering of messages, and an example of where this might be used would be to capture a password message when a legitimate user logs on and later replay it to masquerade as that user.
Repudiation as a threat, as opposed to non-repudiation. Repudiation, whereby the user or the system denies having performed some action, and that might be in the origination of a message. It might be in the receipt of a message, and the example of that would be a physician who might be accused of over prescribing. They may deny having written a prescription.
Then there are other - threats described that are perhaps a little less pertinent to this discussion: Unauthorized disclosure, revealing message contents or other data, but very important for HIPAA, and denial of service, which would prevent the system from performing its functions.
The next document I would like to discuss is E 20-86, which is a standard guide for internet and intranet healthcare security. This covers mechanisms to protect healthcare information transmitted over internets and intranets. The guide covers relevant standards and recommends, where needed, the particular options to be used within those standards.
The significance in use is that the guide recommends security mechanisms for the protection of health information transmitted using internet protocol suite. This includes an overview of security threats, which is actually the same overview, but in order to keep the documents whole and not relying on one another, they are repeated in 20-86 as they were listed in 20-85.
It also provides a relevant overview of cryptography as that is the fundamental technology that is used in a protection scheme. It distinguishes between network and application-level security. It discusses when each level of security for network versus application might be useful, and it makes recommendations for security protocols - specific security protocols and mechanisms, both for network and application security needs.
At the network security level, the network security services protect the data in transit between systems, and this is appropriate where the end system is not trusted by the underlying - the end system is trusted, but the underlying network is not. This is appropriate where the protection is required for all or most of the traffic between systems.
Application security measures are built into a particular application and are independent of the network layer.
It describes where pros and cons of various approaches, considerations are described for efficiency. Considerations are described for making choices relative to cost. Those services which associate data with an originator or recipient, it states, are best at the application layer, and this would be for things such as authentication and non-repudiation. It would not do that at the network layer.
Cryptographic protection across the network is useless without the proper security mechanisms on the other end system, and as we start reaching these networks into organizations and individuals over whom you have no control, they need to be assured that they are providing appropriate access control at the other end of the wire, that their local systems are providing user authentication at that end, that they have proper configuration management, that they are patching and their security updates are all done and not threatening your system via their network, and they must have robust audit procedures in order to capture mischief behavior.
Moving on to the next standards I'm going to discuss 1762, the Standard Guide for Electronic Authentication of Healthcare Information. This defines the document structure associated with a document that must be signed. It describes the characteristics of the process in applying a signature, the minimum requirements for different mechanisms and technologies, and I spelled many of them out last time, so I won't repeat them. The minimum requirements for user identification and access control. It outlines technical details for all of the electronic signature mechanisms in sufficient detail to allow interoperability.
The objective is to create guidelines for entering information into a computer system where the assurance that the information conforms with the principles of accountability, data integrity and non-repudiation are assured. User authentication is used to identify an entity and verify the identity of that entity.
Data origin authentication binds the entity and verification to a piece of information, and the signatures have been a part of the documentation process of healthcare have traditionally been the indicators of accountability, and as we moved into the electronics space, we need to assure that accountability is propagated.
The requirements for E 17-62 include non-repudiation, integrity, secure-user authentication, multiple signatures, signature attributes, counter-signatures, transportability, interoperability, independent verifiability and continuity of that signature capability.
Currently, there are no recognized security techniques that provide non-repudiation in an open network environment in the absence of trusted third parties, other than digital-signature-based techniques.
The generation of electronic signatures requires the successful identification and authentication of the signer at the time of the signature. The standard acknowledges the efforts of the industry and system integrators to achieve authentication with other methods and is, therefore, not restricted to a single technology.
Data and information for which authentication is required, the system needs to provide the signer an accurate representation of that information that they are about to sign. They need to be able to append one or more signatures, particularly in healthcare. They need to include information associated with the assigner, and this may include appending zero or more document identifiers as attributes.
The internal structures of the health-information content are recognized to be defined through other standards. We are not looking to define the message content here, only wrap it.
Mandatory attributes include signature and time. Other attributes for signatures, optionally, would be location, things such as the signer's role, the signer's organization, document links, biometric information, annotation and other optional attributes.
The electronic-signature technology discussed user authentication using passwords. It lists requirements for the communication of passwords when passwords are used. It lists requirements for generation of passwords when passwords are used. It references standards for sound practices of password utilization.
Generally, the common practice of simple user entry of passwords is inadequate to meet the intent of the electronic signature, but recognizing that that is active and in place, we have denied some standards surrounding that.
It also describes the use of secret-key cryptography for user authentication, public-key cryptography, biometric and token-based.
The data-authentication component defines technologies of digital signatures, approaches of private-key protection using password-protected encrypted approaches, public-key authentication, digital-signature representation and secret-key-based data authentication.
Other items that are addressed are time stamps, and there is an informative appendix, including information on digital-signature technology, biometric authentication, time-stamp technologies and organizational policy issues that might be relative to signatures in healthcare.
The next document is E 20-84. The scope of this document is a standard specification for authentication of healthcare information using digital signature. So, whereas, 17-62 is not specific to digital signature technology and is permissive, if you are to use digital-signature technology, this is the standard that has been written to support that.
It covers the uses of digital signatures to provide authentication of healthcare information as described in the guide, E 17-62. It describes how the components of the digital signature systems meet those requirements and includes the specification of allowable algorithms, key management and key formats.
The specification describes one implementation that meets all of the requirements of 17-62. It does not purport to be the only approach.
An overview of the document, the digital signatures are cryptographic technique in which each user is associated with a pair of keys. There is a piece of data associated with a document which allows the recipient to prove the origin of the document and to protect against forgery. The overview describes the concepts of the signing and verification process.
The contents specifies mapping algorithms, procedures and data formats to the electronic-signature requirements from E 17-62. It recommends specific algorithms for the various approaches, public-key management requirements, such as the user shall obtain the signer's public key from a source that he or she trusts, and that is going to be very dependent on the domain in which you are implementing. The specification does not impose any structures on CA's.
The private-key management, the user's private key is intended to be protected from disclosure to others. It recommends to use a tamper-proof cryptographic module, such as a smartcard. However, it also recognizes that it is an acceptable approach to encrypt a secret-key computer from a password entered by the user and stored on removable media, such as a floppy disk - or USB's. The technology moves forward.
Specification for data structures - ASM 1 specifications for the data structures are also defined.
We get now into the PKI security documents.
E 21-22, all of that information was contributed to the ISO TC 215 technical specification for healthcare PKI. So I am actually describing consensus work between the two.
The risk for PKI security - and we heard that loud and clear, particularly from NIST today - would be identity fraud, the ability to trick the CA into issuing a certificate to the wrong person, and this might happen at the time of registration, if you are able to misrepresent yourself to the CA; within the CA management itself, such as the ability to bribe the staff; within the CA hardware or software, if you hack into that machine or physically access the machine and cause it to sign where it wasn't intended; to forge a CA signature, perhaps steal the certification authority's signing key and use it without it knowing it. Credential fraud. Can you trick the registration authority into attesting to the wrong credentials? And the risk of stolen identity. We need to be able to protect the private key, and the users do need to be educated as to their responsibility with that key and that it would be holding their signature.
The requirements for PKI in a healthcare context that we were addressing through the standards objectives are the reliable and secure binding of the unique and distinguished names to the subject, their professional roles in the healthcare space to the subject, and attributes, when they are used, that may be used to secure the communication, such as identifiers. Where do we represent the health identifiers in the standard? And we need a high level of assurance for this infrastructure, infrastructure availability, trust and internet compatibility. We need to facilitate the evaluation and comparison of certificate policies.
The technical specification. Defined essential elements of the healthcare PKI that would support secure movement of information across national boundaries. This includes the authentication of healthcare providers and their roles, the identity of extensions to X 509 certificates to represent the additional information that we are attesting to, such as their healthcare license, to get an agreed set of policies and procedures for authentication and verification of healthcare provider accreditation.
We defined within 17090 a healthcare role extension. This is intended to define minimum policy requirements for the secure binding of the identity to the person and that extension can then represent the healthcare profession. It can represent regulatory identifiers. It can represent professional identifiers, consumer identifiers, health insurance claim numbers, employee roles. We made it general to be able to support any of the healthcare identifier needs.
The document is split into three parts. Part one is a framework and overview. It defines PKI concepts, components and interoperability issues with respect to healthcare. It is much more of an administrative overview in how and where you should use PKI for healthcare.
Part two is a certificate profile. It discusses the detailed ASN 1 specifications and what those - in every single field of the X 509 certificate and the custom extensions that we added.
And part three is the policy management of the certification authority, and this defines the minimal requirements for certificate policies and certification practices for managing a CA.
There are 15 scenarios in part one that include scenarios for authentication, confidentiality, integrity, digital signature, including a scenario for electronic prescribing.
The identities that we discuss at that level are the healthcare professional, whether you are a doctor or a nurse; a healthcare employee, such as medical-records clerks; non-regulated professionals on some locations - midwives or social workers may not be actually regulated healthcare workers, so we need a binding to the healthcare space - supporting organization employees, such as your insurance-claim clerk; and consumers, be they anonymous or identified consumers.
The regulated healthcare organization, such as a pharmacy, if you are going to issue a certificate to a note on the network or to the pharmacy, rather than the pharmacist; supporting healthcare organizations, their billing services.
The authentication of the individual's identity, to get that strong binding. We have defined an in-person registration, a face-to-face within the process, and they must, at that time, demonstrate a government-issued photo ID.
Regulated health professionals shall also present proof of their professional credentials established by the professional regulatory or accrediting body in their jurisdiction. So, in our case, it would be at the state level. In other countries, it may be national.
Non-regulated healthcare employees and sponsored health professionals shall present proof of sponsorship or other binding to the healthcare organization saying that they are either an employee of the healthcare institution or a practitioner. Supporting organizations shall present proof of employment by their supporting health organization as well.
The types of security controls are in accordance with ISO 17799 or other approved accreditation. This addresses the physical controls, procedural controls, personnel controls, network controls, cryptographic module engineering controls, repository management, security audit and records archival associated with the infrastructure.
IHE has a proposed profile that we'll be addressing this year, digital signatures for attestation and authorization. The overview of this is that signatures have been part of the documentation process and the healthcare and traditionally been indicators of accountability.
For electronic-health-record systems to be accepted, they must provide an equivalent or greater level of accurate data entry, accountability and appropriate quality-improvement mechanisms.
In this context, a standard is needed that does not allow a party to successfully deny authorship and reject responsibility through non-repudiation.
Reliance upon the electronic health records and other forms of electronic health information requires an electronic-signature process that provides satisfactory evidence of information's authorship, approval, review or other ownership. In particular, acts of attestation and authorization require a high degree of assurance for accountability and data integrity. As electronic health records are shared across healthcare enterprises, digital signatures can be used to provide such accountability and non-repudiation of signatures used both for attestation and for authorization.
Attestation and authorization require all the security services that digital signatures can offer to check that the prescription is verified as having originated from a particular health professional with appropriate credentials. Ensuring there are no errors in the transmission requires the integrity, service, and accountability requires the service of non-repudiation.
The types of standards that we'll be addressing at this stage through IAT - although we will probably bring in more - are the E 1985 Guide for User Authentication Authorization, the Technical Specification 17090 of healthcare PKI that I just described, the IETFRC's on X 509 P KIX(?), the IETFRC's on S-MIME(?), ASTM 1762, 2084 and 2212 that I have described.
The digital-signature profile will cover the supporting services that may be and that must be invoked as part of the signing processes, the supporting services that may be and that must be invoked as part of the signature-verification processes, the signature attributes for use with digital-signature mechanisms, minimum requirements for user identification, access control and other security requirements that must be in place to ensure the integrity of the signature, types and characteristics of health information requiring signature and associated constraints, requirements and approaches for multiple signatures, requirements and approaches for nested and embedded signatures, requirements for preserving signature integrity and intermediary processing and information forwarding.
The legal environment is determined to be out of scope. Legal constraints surrounding digital-signature constraints are by law.
Separating the signing from the document-signing mechanism and signing generically by format, each having their own mechanisms. The counter-signature and attestation part. The authorization would be linked to workflow, breaking that into a separate part, and the structured documents.
We have a few examples of implementation of the standards. The VHA, Veterans electronic-signature requirements for that project, the requirements that they are adopting are the Government Paperwork Elimination Act, ASTM 17-62, ASTM 20-84 and 21 CFR Part 11.
Kaiser Permanente had also done some activities in deploying a PKI in compliance with the ISO specification.
The Australian HIC is already deploying PKI, although not yet for e-prescribing, and it is under planning in other countries, and Med Plexus(?), formerly I-Trust(?), through AAFP, the EHR pilot study, which Dr. Zuckerman will be demonstrating.
DR. ZUCKERMAN: Okay. Thank you.
I am Alan Zuckerman. I represent the American Academy of Pediatrics to ASTM, and I am also speaking on behalf of Rick Peters, who represents the American Academy of Family Physicians, and I am also beginning work on the certification of interoperability with EHR, including digital signature.
What I would like to take a few minutes to do today is to bring a physician perspective to the everyday use of these standards and try to demonstrate that we can use digital signature today, that it is being used to sign prescriptions in physician offices, and it doesn't have to change workflow or change the appearance of the applications.
It is important, of course, to think of prescriptions as clinical documents and not just messages on the internet. The software which is running in this computer here - but, to save time, I have captured screen shots so we can move a little bit more quickly - is built largely using open-source libraries to implement the standards and modeled in compliance with these standards.
One particular feature that it uses that is a little bit different from the VA demonstration you saw is the concept of creating keys and putting them - when you create the user account - putting them in a lockbox. This, of course, doesn't measure up to the registration standards we would want to go to in the future, but it certainly makes the system very transparent to the user.
The Med Plexus EHR is a commercial product. It has been in use since 1999. It has been the product used in the American Academy of Family Physicians EHR pilot project, also often misnamed an open-source project, which it is not.
There is a CMS-funded evaluation of the implementation in the offices that doesn't deal specifically with digital signature that's nearing completion, but the important message is although the pilot is just in five practices distributed around the country, about 25 physicians or over 40 practices using this - well over 100 physicians - digitally signing prescriptions every day with this software, and it is a full PKI digital signature, but it is completely transparent to the user.
Part of the reason for that is that they have turned off the smartcards, but, in fact, smartcard readers have gotten smaller, and I did want to make the committee aware that these USB devices are full-fledged smartcards, as is this PCMIA card. So we should get away from a pure credit-card model, plugging in these devices, which have both a card and reader function, together show what is happening.
Well, what did I do this morning? I opened a security middleware. I logged on to the EHR, got my cockpit which lists appointments, selected a patient, was able to view the existing prescriptions on file, which included one for Amoxicillin written two days ago, and what I am going to do now is create a new encounter, and, for that encounter, start a new document representing a new prescription, and I need to link that to the encounter because of the way this EHR is structured, and then I select the medication.
What I am doing is going through a common scenario, where if the first antibiotic fails, we are moving to an alternate here, Seftin(?). So the EHR does an alphabetic search, brings me to an e-prescribing screen. I think you have probably seen many of these, and they could also be copying from a template. What is a little bit different here is there a signature button at the bottom of the screen which is asking me to get ready to sign.
When I do get ready to sign, alerts will come up. The prescription is now converted to a document and it is ready to sign, and when I click the sign button it asks if I want to send this by fax, by paper, and, today, this has been expanded to SureScripts as well, but I don't have the SureScripts software here with me today, and when you sign, you reenter the PIN.
So, in effect, if you are configured to require the smartcard, we have the smartcard as one factor, and we have the user's PIN that is entered just in time to complete the transaction, and the prescription is now sitting there in EHR on the printer or as a PDF that we can email is the prescription.
But, now, let's bail out of the EHR application, take a look at the internals to show you that while this conventional process has gone on, we have also generated the PKI.
Here, in a particular directory, residing on my hard disk is a print file which is the XML prescription, and here you can see the prescription itself. Medication is Seftin. It has quantity, frequency, all the usual fields. This is very similar to the SureScripts XML prescription structure. In fact, the translation is now being done.
What happens next is we have a signature section, as prescribed in the ASTM standards that have been followed, which includes this string of characters here which is that encrypted message digest encrypted with the private key of the user, as we have had presented previously, and it also has the information about the prescriber, and ID link is encrypted, the time of the signature, all the other types of fields as prescribed by the standard, and it just is generated as part of clicking on the signature, and the method of storing the keys is a very important part of that. These are residing on this computer in a keys directory and for each of the users there is a subdirectory which has four files in it. One is that triple-DES key for symmetric encryption, so that we can store data and transmit it. There is a user-password file. There is a private key and there is a public key. Well, these are sitting here right out in the open, so something seems wrong, but when you open them up - and I am opening it just in Notepad and we can do it later - they have been encrypted, and so they are not useable, because they have been encrypted by the security middleware. It works pretty much like a safe-deposit box in a bank. To actually use this key, you need to have the user's PIN to unlock the box, but you also have to have the bank's key to open up this lockbox, which is holding the private-key credentials.
Also, if you look out, we have properties here, and we have these various software JAVA jar files, which are themselves digitally signed. Instead of using a virus checker to see that no one has tampered with the cryptographic module or with EHR application, they are digitally signed, so that you can tell if the software has in any way been modified, and if we open the property's file, you can see there are just a few lines of code to convert from this lockbox folder, which can be on the client or on the server, to a smartcard, and we could enable a particular smartcard and link to the appropriate cryptographic library with 60 seconds of editing a configuration file.
If we now move over to the sequel server and open up the actual data objects and you look inside the database record, this prescription for Seftin has the generic and brand name, and it has all the specifics and details in XML stored within the database to hold all of the XML prescription.
We also have a separate object for the document itself, which actually has the complete XML of the entire document from start to finish, whether it is a clinical note or a prescription, and in that document we have a series of fields for the name of the signer and the type of the signature, the time it was signed, and all of the other signature fields are stored here in the database, all this happening multiple times a day without the physicians even being aware that a signature has been placed on record, and when the prescriptions are sent outside, we simply leave the prescriptions behind.
And in terms of registering the user, these keys, and the whole process, is just a consequence of creating a new-user account with administrator credentials, but what would be necessary to take an application like this to the next level would be to involve a third party, at this point, to bring in the certification from someone such as the DEA or their sub-CA authorities.
And the points I'm trying to make is just that PKI digital signature actually is in use. It can be totally user friendly and transparent. The standards - we protect the keys. We have a lot of different ways of protecting them, such as this lockbox approach or simple smartcards that can be made not too intrusive. They require that we use specific cryptographic modules, and in the appendix of all the standards, there is an exact list, and those plug-in module jar files that I showed you implement the particular SHA 1 and DSA signature algorithms that are used by this application, and they also require that we capture and save some fields on the signature and attach that to the record of the document. You saw both in the database representation and in the XML document that it is not overly difficult to comply with the standards and put in the relevant parameters, including the algorithms used, into the document record.
And the conclusion that I hope you will share with me, that is, if we simply the registration process and we don't require extremely expensive add-ons, such as biometrics, this type of activity is feasible, and if we actually encrypt keys and consider leaving them on servers under appropriate protection of smartcards and other tokens that we can have applications that function totally without the knowledge or interference of the physician's normal workflow, and the experience of the past year in this EHR project, which has this buried within the software, has pretty much shown that. Most of the physicians totally unaware that digital signatures are there along with their name on every document that they have signed.
Thank you.
DR. COHN: Okay. Thank you all very much for some very interesting presentations.
Questions from the subcommittee? Stan, you had a question, please.
DR. HUFF: The one thing - I think the one question, even since the previous presentation, that I had was when do we really need this? And what I mean by that is, I mean, within our institution, at least, you know, regular log-in and password and other things have seemed to be sufficient for all of our business needs, and why - granted, it is feasible, but why would we go - I think everybody would grant that it is at least extra work and extra software, even if you can make it invisible in the application. So what are the use cases when you see that this extra level of non-repudiation and security are needed?
MS. FORQUET: When you are outside of the control of the other entity in that organization to whom you are communicating with, you can no longer apply sanctions and some of the other security processes and mechanisms that we do to assure a secure system.
DR. HUFF: But in - I mean, both in the - that is typically not the situation I ever deal with.
MS. FORQUET: Um-hum -
DR. HUFF: And in the e-prescribing networks that we are conjecturing, that is not the situation either.
MS. FORQUET: As you start moving into an electronic-health environment where you are not necessarily dealing with clinicians and providers that are a part of your controlled network, that is when you start needing to cross the control boundaries of domain and have interoperability issues. So -
DR. HUFF: So it's the environment where we conjecture that, for instance, the patient is holding their record, which is an aggregation of many records that were generated by authoritative physicians or providers or others who contributed information to that record where you see the greatest utility?
MS. FORQUET: That is one scenario. The other would be the local health-information infrastructures where you are trying to build a longitudinal record within a community, within a region and try to better service the quality and cost of health care.
DR. HUFF: But that would then seem to be problematic in terms - if I am dealing either in an LHII or in a personal record that was held with these, now, I am not trying to decrypt one signature. I've got, potentially, hundreds or thousands of documents, all of which have certificates and private keys, and I am going to have to have access, then, to some directory of public keys in order to decrypt or to verify the validity of that information. Is that true -
MS. FORQUET: Let me distinguish it is not the encryption. The encryption is -
DR. HUFF: Yes, I said that wrong, but in order to verify that that data is accurate, I am going to have to have access to potentially hundreds or thousands of public keys.
MS. FORQUET: Key directories is one approach, and, as I indicated, we do have an ISO standard to address that kind of a community directory, but, also, what is typical when you sign a document is to send your certificate along with the document, so it can be verified, so, in most cases, you are not even needing to look it up in the directory.
DR. ZUCKERMAN: That was what the DEA told us this morning they want to happen. They want the public key to travel with the prescriptions. When a physician releases that prescription, whether an LHII or a pharmacy, a public key is there to verify it, and that was what the VA was doing that the VA didn't have to have directories, that the prescriptions, as sent by the people who are writing them, could be verified from internal information in the document.
MR. GLICKMAN: Can I say something? I mean, am I allowed to say something? To answer -
DR. COHN: Sure. We are going to be transitioning to open mike anyway soon. So I want you to come to a microphone, introduce yourself and make a comment.
MR. GLICKMAN: Well, I just - Are you going to still have the open mike -
DR. COHN: No, we will -
MR. GLICKMAN: Okay.
DR. COHN: We were transitioning to that in minutes anyway.
MR. GLICKMAN: This is Mike Glickman. I'll make some comments when the open-mike session comes, but in terms of the user name and password, that really works best in a closed system, and the issue is if you looked this morning at what was working for the gateway-oriented network environments that the e-prescribing vendors were using, it is a simpler problem.
So the idea is that the only really established way to have non-repudiation is through some form of PKI. It is not going to be user name and password. You know, that isn't really a digital signature.
So if you were able to have a two-step process, for example, where all you had to do was authenticate that I knew I had a public key once before and stored that away, even if I am doing a personal health record, I am the one that dealt with the doctor in the first place. I will have one instance of his public key, and then when another one comes along, it is not that I am going to have to look at thousands of other people, I'll take the public key. It'll be a second instance. I'll run it through the algorithm and it'll work.
So I just see that, in a closed system, it is a simpler problem. In an open system - in the open internet, it is a much more complex problem, and we don't want to do it twice.
DR. COHN: Harry had a question.
MR. REYNOLDS: Yes. Dr. Zuckerman, take me through, with the digital signature and everything - and the PKI you had in there, take me through that if it leaves your office and goes through four or five other points and is translated and has the other things happen to it that we all talked about today and can happen, help me with how that stays intact.
DR. ZUCKERMAN: Well, if we are going to be compliant with our signature standards, and if we are going to be interoperable, the only thing we can sign is what leaves the office, and so the original document probably has to travel from that point end to end. Whatever other translations, whatever other events are done, they will be a second document that might be signed or counter signed by another intermediary, but the essence of the standards, the essence of the method is that the signature is totally dependent upon the document which is being signed.
Now, on the other hand, much of the information in electronic prescriptions really aren't being translated. They are being reformatted, and the only thing that is changing is the punctuation and the labels that surround data which itself is constant, and if we develop very good translators and we have certain XSLT, XML translator programs we could move from one format to another without touching the internal content, and if someone would certify interoperability of two different formats, you could never move the signature, but you could at least verify that the data, as it originally left the office, hasn't been changed in any of the key fields of content when it arrives at its final destination in a slightly different-appearing way, but if you change the drug name, if you re-code it, if you substitute different names - but as long as you have all of the content remain constant, then there is not a problem.
MR. REYNOLDS: I'm still not comfortable I got an answer. I mean -
DR. ZUCKERMAN: Again –
MR. REYNOLDS: No, no, no, the reason I am saying it is I think I heard you initially start off and say there might be two documents, one that goes straight to the pharmacy that says, Hey, I have signed this and I am sending it to you, and, oh, by the way, it may come through another path, but when it gets there, I did it.
DR. ZUCKERMAN: The only way you could verify that you did it is verify the signature on the first document and then field by field match the content.
MR. REYNOLDS: Okay. Okay. Thank you.
DR. COHN: Steve, I think the last question and then we'll move into open mike.
DR. STEINDEL: Yes, I have, first a comment and then a question.
It sounds like one of the deliberations that we have to reach is - prescribing world what constitutes a closed system, because that seems to be somewhat of the key of how much risk is involved with this and whether or not we consider the e-prescribing system is defined to us sufficiently closed because of the agreements. That is what I heard somewhat from NIST and what I even just heard right now. You know, that if we could define it as some type of closed system, then what we need to do with it is less.
Now, I have a question concerning the application that you showed. Where is the certificate? How is the certificate generated?
DR. ZUCKERMAN: Unfortunately, in this application, which was written earlier, they are not using typical certificates. Instead, the fields that would create a certificate are generated during the user-account creation and they are working, now, to package them as a certificate. This is not up to the standards of certificates. To use this in a full certificate-based, third-party-authenticated world, you have to bring the certificate in or actually obtain it during your user-enrollment process within the application, because it is a closed system, and they are generating their own certificates. They are self-signing their certificates; that is, in effect, there is a certificate, but it is self-signed by the same vendor that is providing the application.
DR. STEINDEL: Yes, and from what I - my understanding of a PKI that is being used outside of a closed system, I mean, where your biggest problem comes about is with the cert -
DR. ZUCKERMAN: Absolutely.
DR. STEINDEL: And I think anyone would agree that what you were showing with your application, while it was very similar to what Stan is doing with his application - it may have little twists and turns that are different - but the big problem is when we are looking at the cert itself and how it is verified as being correct and still in effect, et cetera, especially when we have to go through 15 bridging authorities to try to trace it back, and that is a real-world situation.
Thank you.
DR. COHN: Thank you all very much. Really appreciate it, and I think we are just going to have to mull over how this applies to everything else, I guess, is really going to be part of the question, but thank you. Very useful.
DR. COHN: Okay. Why don't we move to open microphone? Do we have anybody who would like to make any comments?
Ross, would you like to introduce yourself and make a comment?
MR. MARTIN: Ross Martin from Pfizer.
Actually, I have a question for Dr. Zuckerman, before he leaves.
Based on the DEA presentation from this morning, it doesn't sound as though - even though you are using PKI in this situation - that it would pass muster with what they are sort of proposing for Schedule II medications. Would you agree with that?
DR. ZUCKERMAN: Yes, but it is not a major process to adapt it to certificates that they issued, place them into the smartcards and tweak the software so that it will work with it, because we are working with the same standards.
The key is the DEA, in their documents, have said they are going to use specific certified algorithms. These are the same ones that exist in this library. Just tweaking the configuration to point to a smartcard that they have generated. Once you get past the registration - It takes me a long time to register with the DEA for a paper certificate. Once you get past that hurdle, then you just plug your certificate in. You can use an application exactly like this, as long as they don't require the biometrics, and if they do, there are ways to work around that, but it is a little more obvious to the physician.
So everything you have seen today could work with a DEA-issued certificate, but you have to go through that process first.
MR. MARTIN: Yes, I guess my point in that is I am just concerned that the very parts that you have to add back in are the ones that are the most cumbersome, and I think you guys all see that, too.
I wanted to just ask if - as we move toward the timing of when PKI would be required, and if there are interim steps, and if you are going to make any recommendations about the other things that could pass muster - For example, within the e-prescribing environment, if we could test against Medicare Part D provisions along with - and try to get this tested with the DEA - whether or not the model of sending the electronic prescription for Schedule II just as a normal prescription, printing off a copy of it, having a wet signature on that with a printed script, so that - because the DEA language isn't clear to me whether or not the entire prescription has to be handwritten or a wet signature is required or a handwritten signature is required on a printed script, and I think it is the former, but if you could have a printed script with a wet signature on it that accompanies the patient, so that when they pick up the prescription that was delivered electronically, you've got the best of both worlds, if you will. You've got this thing that is required today of the validated signature, but you've got all the checks and balances and audit-trail capabilities of the electronic process going in conjunction, and you have something that is not very different from what you do for everything else. The only additional step is printing out, or, in the case of what Goldstandard was doing, faxing back a copy for the doctor to sign and hand to the patient.
MS. FRIEDMAN: Why would you want to do that? It seems like double work.
MR. MARTIN: The only double work is for Schedule II controlled substances.
MS. FRIEDMAN: I know, but I'm saying that why would you want to do that, because you are dropping back to paper anyway, so why bother? Why bother with the electronic portion when you are just dropping back to paper -
MR. MARTIN: Because you get the drug checks. You get the opportunity for the fill notification that says, yes, this written prescription that otherwise would have no other connection to everything else that you are doing electronically with electronic medical record, with all these other opportunities that e-prescribing provides, and you are also not having to write out the entire prescription. All you are doing is signing it.
So there is very little double work, I would contend, with doing it that way. You are just validating it through another channel, which is kind of what you need - that extra assurance that you need, and it seems that that could, potentially, fulfill the DEA requirement, but I would like to test that.
DR. ZUCKERMAN: Can I just mention that that is normative practice, but depends on the exact local regions, because some states are requiring special paper, other copies, but, at least in this region, this is what many of the physicians do, we do write our controlled-substance prescriptions using e-prescribing, hand sign them on paper, hand them to the patient. Still means the patient has to come into the office, because there are no refills and -
MR. MARTIN: Do you electronically sign - I mean, do you electronically deliver a copy of the prescription -
DR. ZUCKERMAN: You are not allowed to.
MR. MARTIN: That is my point is that you also want that part of it to happen as well.
DR. COHN: I hear where you are going, Ross, but I am not sure that that is a critical piece, since, if you think about it, if you do it electronically, locally, you are doing all the drug checks, and, at the pharmacy, they still have to enter it into their database, and then they are, once again, doing the drug check. So I think you are sort of getting both of those, I think, if you think about it. I mean, you are getting sort of both. So, I mean, you know - what I am saying is that your solution isn't the only one to get the drug checks involved. So - but it is a reasonable thing to think about.
Any other comments or - Okay. Thanks.
Please.
MR. GLICKMAN: Well, good afternoon. I thank you for the opportunity for the open mike and a chance to address this group.
My name is Michael Glickman. I am with Computer Network Architects. I am one of the original 12 members of the HL-7 Working Group, involved since about March of 1987.
I am also the First Chair of the HIMS EHR Steering Committee. I am involved with TC 215, Working Group Two, on messaging and communications, and our group is currently coordinating and serving as a liaison on an international scale with the IEEE with medical devices, HL-7, and, recently - though it has taken about 4-1/2 years, when I say recently - the Dicom(?) community has been involved in liaisoning with the ISO world as well.
One point I wanted to make to the group - and I am sure you all know it, but kind of for the record, if you will - that it is exponentially easier to coordinate standards up front than it is to try to harmonize them after the fact.
So one thing that I wanted to say is that a digital signature must provide not just - to be truly a signature in the original sense of the world, it must provide not just authentication - and audit, but it also has to provide non-repudiation.
I have heard the phrase non-repudiation used a lot of ways today, and the one that comes out of the standards and the one that was mentioned by the NIST people is the prevention of an entity from denying previous actions. That is a very important point.
PKI, I think, is recognized as truly a highly scalable and well-established method to establish and maintain security between trusted parties, but there are a lot of other ways to do it.
I think the e-prescribing group that testified earlier was solving a simpler problem, if you will. It is kind of like - you know, a lot of us are scientists in the room, but solving mechanics and thermodynamics and you avoid friction. You know, it makes the mathematics a lot easier.
The notion is when you have gateways and a closed system and centralized processing, I mean, that is what it takes to deliver a product today, and these groups have delivered successful products, but they have, to a certain extent, ignored the kind of problem that you all are - the daunting test that you all have to face, and that is how does it work in a larger environment and how will it work effectively in an open environment.
So - the groups that also testified earlier, and all of the local and - you know - enterprise-specific implementations have implemented policies and procedures, and they have implemented service levels and trading-partner agreements. So that it is not just the PKI infrastructure. If you would just say, let's mandate PKI, that wouldn't get us any closer to non-repudiation, you know, at the end of the day - that would be a lot of days - than it would today.
The notion is that we also - you know, I am sure in those service-level agreements that wasn't mentioned today there's probably remedies and liquidated damages and other sanctions that are associated with disclosing that information. So it is not so much - you know - PKI, per se. It is the fact that we want to have a method, if we are going to do a digital signature, if we are going to follow the paradigm that I can sign it and only I can sign it. Others can verify that it's me and that I can't deny it after the fact. Those are three very important attributes of a digital signature, no matter how it is implemented and how it is communicated.
So I guess what I ask the group, you know, having been involved in all the coordinating efforts - realize we have had - the ANSI HISBY(?) was preceded by the ANSI HISPP, which was preceded by HIS SEESAY(?), and I am talking about 16 years ago, and Dicom, when they started was in 1982, when the ASTM - when the - I'm sorry. That's the other guy - when the ACR, American College of Radiologists and National Electrical Manufacturers Association got together and decided that having to buy all of your radiology material from one vendor is not necessarily the way the future is headed. It has just taken 23 years to have implementable systems.
So I guess one last parting comment that I wanted to make to the group is that there is an awful lot of existing infrastructure in place and you are asking for many of those groups to present to you. Clearly, NCPDP is going to be the subject-matter expert for the prescription information, the pharmacy information, all of that.
You know, there is also, of course, ANSI through the HISB, which represents a lot of efforts in healthcare. It is the only remaining information standards board. There was the Information Systems Standards Board, and that was the one that ended about a year-and-a-half ago. There is also HL-7, and, of course, the ISO TC 215 efforts that are available to you, and then the HIMS IHE, which is really serving as an implementation guide in kind of a live demo year after year, and they have added, over the years. You know, realize it started about 15 or maybe 11 years ago with just Dicom. Then it was Dicom with HL-7. Then it was Dicom, HL-7 and HIMS, and, this year, in February, in Dallas, it is going to also involve the government in what is called an Interoperability Showcase. So those are all existing methods, and I encourage you to consider some form of what HL-7 and other groups have called in various phrases some kind of draft standard for technical use or trial use. I'm sorry, draft standard for trial use, but the notion of either using IHE profiles or using an HL-7 draft standard for technical use, but coming up with some way where we try it out first and try to avoid this one-size-fits-all approach that is never going to fit everybody.
And those are my comments. I appreciate the opportunity.
I can answer any questions, if you have any.
DR. COHN: I'm not sure I have a question, but it's great to hear from you, and I guess listening to what you have been doing, I can understand why I haven't seen you for years. You have been in Europe - (laughter) - and other parts of the world, sounds like -
MR. GLICKMAN: Many of our meetings are here, but, yes.
DR. COHN: Yes, exactly. So - Are there other comments from - I mean, thank you for your comments. I think they are timely. Other comments from the subcommittee? Steve.
DR. STEINDEL: The NIST publication, non-repudiation was referred to in the comments that were just made, and what I was impressed with was how he introduced that, because he introduced it with the term technical non-repudiation, and that was a little twist, because there are many, many ways to do non-repudiation, and, you know, some of the technical methods, like a hash method or something like that, we have had comments about the appropriateness of it in this environment and the audit trails, et cetera, and we have heard some instances today about how that was used successfully for non-repudiation.
So there's many ways you can do non-repudiation. I think we need to remember the difference that NIST talked about about technical non-repudiation and non-repudiation in general in our deliberations.
MR. GLICKMAN: I think a lot of people are using non-repudiation and are really talking about data integrity. You know, the idea that data gets there - arrive intact. Whether it gets translated or not, as long as it is translated one to one - according to the rules, it's fine.
DR. COHN: Thank you.
Other comments, statements from the -
DR. HUFF: I just -
DR. COHN: Oh, please.
DR. HUFF: I think I heard everything you said, and I - but if you were to summarize - I mean, if you wanted to say very specifically what you would like this committee to do, what is it you would like this committee to do?
MR. GLICKMAN: Me personally?
DR. HUFF: Yes.
MR. GLICKMAN: Tread lightly on PKI - using PKI, so that all of the rest is worked out, and recognize that the issue is to have what we consider today a digital signature, that a user name and password, per se, isn't going to pass muster in the long run, and the way to get there is going to be to try it, test it, do some prototyping first, so that we only have to do it once and we avoid the harmonization downstream.
DR. COHN: Okay.
MR. GLICKMAN: And there's lots of resources available already and infrastructure in place to try that out, not just HIMS and a lot of standards development groups as well.
Whether you agree or not, have I communicated what I -
DR. HUFF: Yes, I understand.
DR. STEINDEL: I wasn't sure if you were here before lunch. I don't remember, but when Karen Trudel was giving the CMS update, and, basically, what they are - CMS - is thinking about is extensive pilots to test this before it does go into place. So we already are thinking about exactly what you are proposing.
MR. GLICKMAN: And I guess so I'm adding, but there are some already - you know, infrastructure well represented by industry and users that could help in that process.
DR. COHN: Thank you.
Other comments, statements from the turn for our open mike?
Agenda Item: Subcommittee Discussion
DR. COHN: Okay. Well, let's move into subcommittee discussions, and sort of - sort of looking around at everybody here.
Oh, I - Okay. I think we are going to move, now, into sort of a little session talking about sort of what we heard and sort of next steps, and I certainly do want to remind everyone that - I mean, we'll have some time I think tonight to reflect on things, and if there's time tomorrow, we can sort of do a final sort of summation of all of this, but, of course, we do have hearings and meetings scheduled for February 1st and 2nd to sort of try to come to, hopefully, whatever final agreement, or at least next-step agreement in terms of what it is that we may want to be recommending to the full committee, knowing that - I think our plan had been to come with recommendations relating to this, updates on the other recommendations we made in our first letter, as well as, I think, a letter that also includes privacy and confidentiality recommendations from the Subcommittee on Privacy and Confidentiality from the hearings that they have already had.
So I guess I am just sort of curious about what others think at this point. What sort of frames or learnings you have had from today that we need to have Margret try to capture while things are still fresh.
I think my own view, at this point - unless I hear otherwise from you - is that probably we will limit our session in February to two days.
I would imagine that likely, just knowing our drafting approach, that, hopefully, by February, and maybe a little before, we'll begin to have things sketched out - at least some of the aspects - but then there'll be, probably, a series of conference calls in February, hopefully, none of which will last eight hours again, but that will be cause to allow us to sort of refine the letter prior to the March schedule, and I am just sort of speaking right now of process. Hopefully, people are comfortable with that process, but, once again, no eight-hour conference calls. We'll try to be respectful of everyone's time.
MS. GILBERTSON: Are you looking at two full days, February 1st and 2nd?
DR. COHN: Okay. There was a question about whether we are looking at two full days, February 1st and 2nd.
I think we are going to have to let the agenda and schedule - I mean, sort of help us schedule. I guess I am hoping not, but I have no idea at this point.
MS. GILBERTSON: Oh, okay.
DR. COHN: I think we'll have a better idea maybe tomorrow, if that is at all helpful. I am sure a lot of people would prefer it not to be two full days, if that helps you at all, and - what?
DR. WARREN: It can go to three.
DR. COHN: Okay. Okay. So, anyway, do people have thoughts, comments? I mean, I think we have heard today, among other things, about - and just things to reflect on - that there may be a role for the pilots in 2006 to help clarify some issues.
I would also, I think, at least from my perspective, suggest that probably there is very little black or white in the subject matter, and that probably there's recommendations that will likely be somewhere in the middle, at least from my sense of things, and I guess I am hearing - and I guess I need to go back and re-review things from previous testimony, but I think, at least from my perspective, I am hearing that there is a world of routine e-prescribing. There is something that we are going to have to think about that relates to controlled substances that relate to Schedule V, IV and III, and then there seems to be maybe a very different world that is Schedule II, and so, once again, nothing is black and white in all of this stuff, and I would just suggest that we sort of think about them, and, potentially, those buckets, knowing that - we may decide that two of the buckets may be really one bucket or whatever, but I think they are useful constructs to consider, certainly, based on some of the DEA testimony and others, and, obviously, I do want to thank the DEA for coming and talking with us.
So I'll stop there. That's just sort of some constructs.
Jeff, Steve, do you have some comments at this point?
DR. STEINDEL: No, I think, Simon, you have summed it up very well.
DR. COHN: God, I meant to start the conversation. I didn't mean to sum it up.
DR. STEINDEL: I think we have heard a lot and I think we are thinking - starting to see a lot of clarity.
DR. COHN: Okay.
DR. STEINDEL: Just a matter of putting it together, which we'll let Margret do. (Laughter).
DR. COHN: That is well said.
Harry, do you have any comments at this point?
MR. REYNOLDS: Yes, a little bit like Steve, I feel that it is coming clearer, and, at least, I am starting to get a sense of what I would feel comfortable recommending as far as to start the pilots versus later on in the pilot, you know, the Schedule II we heard today and other things, whether or not that ought to be in the pilots or whether we exclude things like that, because, obviously, you know, the DEA put down a rather firm stance about how they are going to want that authenticated and if the industry can't get there by that time to do good pilots or get going on the pilots or if it causes a complete overhaul of the current things that are in place, then you might not get as thorough a look at the other things going on in e-prescribing as we might have, if we started out a little slower, which I think - what we heard.
The other thing I still struggle with, which I - we talked a lot about smartcards and we talked a lot about - you know - the other things that we can use, the USB's and everything else. Problem is, I always keep standing in my doctor's office looking at his PDA, and those things don't quite work the same way as some of the others.
So, again, if one of our focuses is to truly get to the individual practitioner and truly make it useable to them, and we talk about being somewhat technology independent, I am not sure that some of these, at the present time, may or may not almost force a technology focus where you have - and I'm giving - You asked for our thoughts.
DR. COHN: Sure -
MR. REYNOLDS: I am trying to formulate some things.
The other thing is I really like the idea of the pharmacy sending a message back to the doctor's office or to whoever sent it, because I think that - any time you look at some kind of an audit process or - that is a closed loop.
DR. COHN: Yes. Harry, am I wrong or is that the fill notification -
MR. REYNOLDS: Yes, it is. It is, but I am saying I'm - yes, but what I am saying is I'm saying that maybe that ought to absolutely be - Before, we got into the privacy side of that and we started talking about a lot of other things, whether that would be an issue.
I think from a standpoint of auditing and everything else, now, and further certification that this happened and the right people were involved, I think that it has taken on a much - maybe even more of a position for me than it did before.
DR. COHN: Okay. So what I am hearing for you, you are saying that it actually may be a tool for non-repudiation.
MR. REYNOLDS: Yes, because, again, if you listened to all the - I think we are still looking into this whole tiered thing, and we've still got this struggle of this whole transmission of the prescription, you know, going through all the entities, and how do you really get some kind of a tiered -
You know, non-repudiation takes on a lot of forms. Sometimes, it takes a closed loop. Sometimes, it takes lots of other things. You know, some people want it to be a closed system. Other times, it might be a closed loop. Might be other ways of doing it. I'm not designing it now, but I am just trying to come up with ways that would allow it to truly get back and truly close it, so that somebody could pull the plug right away if they saw an issue, because I think - one thing I heard I didn't agree with today necessarily in the discussion, this - the reason I think this is different than HIPAA, I think it's standards, and that's fine, but I think the difference - most of the HIPAA transactions are after the fact and they are actually not administering patient care. You know, they are kind of the claim comes in after it happened, and that's fine. You are documenting patient care. That is a fact. You are paying for patient care. You are talking about eligibility. You are talking about claim status. You are talking about the other transactions that are out there. You are sending something from one entity to another. Somebody gets it. They get treated. So we are in a little different part of the game. So that is why - so, as you think about it, I think it is a little different than some of the - you know, people were mentioning you don't have to - maybe you can look at it like HIPAA. It's a little different. Might be under the same kind of philosophy and jurisdiction, but it is a little different as far as what it is actually delivering, and that is - I don't want to be too callous about saying it is just like HIPAA.
DR. COHN: Okay. And I think, Margret, did you have a comment or a question?
MS. AMATAYAKUL: I had a question about the fill status notification versus the acknowledgment of receipt, and maybe the NCPDP - okay. Great. Does the acknowledgment of receipt of the new prescription describe the content of the prescription that would close the loop for Harry or is it, in fact, the fill status that does that?
MS. GILBERTSON: Remember, these are all real-time transactions. So for every real-time transaction, there can be a real-time response, and there are tie-back fields that say, This is the message you sent me. This is what I am responding to, and this is what I am telling you. So I can either tell you I am sending you a status back with all your trace specs, you know which message I am talking about and who I am, and here is the status of the message received. Thank you very much, whatever, or there was an error somewhere, and this is who generated the error and what it is about. So you have the real-time request response situation going on.
After that - after the prescription has actually been dispensed to the patient and they walk out or whatever the situation is, then the fill status would occur. That, once again, is a real-time request and response. Sent you the fill status. You acknowledge that you got it back.
MR. REYNOLDS: But is it - like if you think of HIPAA, there's a - you know, on the transactions there is a TA-1 that says, I got it and everything is okay and we're fine or 997 that says. Other portions of it, you have the original transaction that you sent also. With what you are talking about, do they actually contain the drug and the other things coming back or are these acknowledgments, Hey, I got it. Thank you. Hey, I am working on it -
MS. GILBERTSON: These are not axe and axe(?). No, these are not just thanks. This is enough - You cannot construct the entire new fill request - the new request. You could, but we don't - you don't have to send the drug segment. You don't have to send the patient segment. You can send some of those, if you want to, but it is enough to say, This is who I am. This is when you sent it. This is your trace-back that you sent me to acknowledge that we are talking about the same transaction. So it is not at the level of a 997. It is deeper than that.
DR. COHN: Margret probably - a little more clarification that she needs. Please go ahead.
MS. AMATAYAKUL: Well, no, it led to another question -
DR. COHN: Oh, please.
MS. AMATAYAKUL: - in followup to that.
So a trading-partner agreement would be needed to determine the content of the tie-back message. So if, in fact, you wanted to be able to detect fraud and abuse in ordering a narcotic, let's say, then you would need either more than what is coming in the tie-back normally or you would have to have a trading partner-agreement that says, I want more than what you normally send as an acknowledgment of the receipt.
MS. GILBERTSON: Not quite sure I am following. Me, as the originator, determines this is what I want, and when you send me a response back, you must echo what I put in that information. You can't monkey with it, whatever. That is my tie-back that you received and sent back.
MS. AMATAYAKUL: I got it.
MR. REYNOLDS: But I'm not sure that the committee - I guess - I'm not sure - maybe it would be worthwhile for the committee to make sure that enough information goes back in a way that the doctor's office would at least know what - not just that a transaction occurred, but the basics of that transaction that are easily identifiable back to the - easily identifiable as to, Hey, who is this person and this drug -
MR. GLICKMAN: (Off mike).
MR. REYNOLDS: Yes. Yes, see, that - I think those kind of things, since the data is available and since there is stuff going back and forth. The same thing we have all messed with on the HIPAA transactions. So you are not asking for new data -
DR. COHN: Okay. Well, I was just going to ask Lynne again, and I apologize for making you come back to the microphone, and I think I hear where Harry is going. I just couldn't tell quite from what you were saying what that is exactly and what that means in terms of your world, which is NCPDP script. I mean, does that - you know, saying that something like that should happen, is that something that is easily implemented by everybody or does that require specific business practices on the part of the originator or what are we talking about here? Is that a change to your standard? Is that making something that has been optional now required? I mean, what are we talking about here?
MS. GILBERTSON: I can't answer fully. I don't have the status message in my head as to exactly which segments are all mandatory, optional or not used. I would have to look it up tonight and let you know.
DR. COHN: Okay. That's fine. I just - I'm hearing - I just don't know what it means in terms of - I mean, if one were to pursue a recommendation like that, I was looking for what exactly it means and what it would have to look like to become actionable in terms of your view, as opposed to something that you would scratch your head about and go, That was sort of interesting. I wonder what they are talking about.
So, obviously, this would be something helpful to sort of understand where you are, you know, what's - I mean, how that all works there. So if you can look - and you don't have to do it tonight. You can send a note, if you want to, over the next week or two, if that would be better.
MS. GILBERTSON: Okay. No problem.
DR. COHN: Okay. Thanks.
Steve.
Lynne, please stay.
DR. STEINDEL: No, you can't sneak away. You brought up -
MS. GILBERTSON: No, I just want to write myself a note.
Okay.
DR. STEINDEL: The fill-status notification, that would be sent if the prescription - when the prescription was picked up. So if a prescription - Ross is shaking his head.
MR. MARTIN: - when it was taken out of the bottle and put into the -
MS. GILBERTSON: No.
DR. STEINDEL: No.
MS. GILBERTSON: No, no, no.
MR. MARTIN: Well, we are talking about - we are changing that. I mean, that's the whole thing -
MS. GILBERTSON: Well, we are clarifying that when it's used - that's right. It is when it is dispensed or returned to stock.
DR. STEINDEL: So it could be like days or something -
MS. GILBERTSON: Yes.
DR. STEINDEL: So from a non-repudiation point of view, there may be a temporal lag that could cause some problems. If we are talking about the acknowledgment message, whatever you call it, within NCPDP, is this something that the clinician would normally receive and store in their record? That is question one.
And question two, do we have any issues concerning the different versions of the standard, so, you know, right now, we have heard a lot about talking - translating it one way. Are we going to have to worry about translating it going back?
MS. GILBERTSON: I mean, if we are - different versions of the script standard, no. Those are all foundation messages that have been in there since time began and are usable.
We are talking about HL-7 to NCPDP mapping the project. Those transactions are considered - not only the request, but also the responses and we are mapping those as well.
Yes, there could be a temporal lag on the kill-status notification. That part, yes, that's true. The other ones are real time, so you are hanging on the line and within 55 seconds you are getting a response back, so there is not a temporal lag -
DR. COHN: Yes, and I guess I would have to remind Lynne Gilbertson we need to - since we are on the internet, you need to - your identity, yes.
And the other speaker was Ross Martin, who had not been identified. So -
Are there other comments? Stan, did you have anything you wanted to share?
DR. HUFF: Well, you know, I just pulled out the letter to remember what was on our we-might-do-in-the-future list, and e-prescribing was there, and looking at the other things on there, the things that - the most important to me after a couple of months perspective were whether we wanted to ever tackle any more about non-drug allergens, a code system for non-drug allergens, you know, things that are pertinent to e-prescribing, but aren't drugs, like, you know, latex and egg yolk and - So that was one thing.
And the other one was the whole issue of medical-history sharing, and I don't know if we want to take those up or not, but those look like probably the most important things on there that we hadn't really addressed.
DR. COHN: Steve, and then I'll make a comment.
DR. STEINDEL: Yes, just a comment on allergens. CHI has kicked off a work group on that, so we would probably be asked sometime in the near future in our previous role of reviewing CHI standards to make comments on an allergen list at that point. So that is actually in the works at this point in time.
DR. HUFF: Okay. That's good to know.
DR. COHN: Yes, and I believe that medical history, which is, I think, what you were talking about, as I remembered - I am having to think back to the actual MMA, which I am getting pretty good at - but I believe that that was potentially a different time schedule than the rest of these things.
DR. HUFF: Heads nodding behind you.
DR. COHN: Am I correct on that? I said it was on a different time schedule, that there was not the same requirements for timing or implementation as the rest of these things. So all I am suggesting is it gives us a little more time.
I guess I would - I may be wrong, and we can certainly decide - we can put this on as an issue for us to discuss either tomorrow or in February, but it is hard for me to imagine that we'll be able to solve the whole medical history issue in - adding one day in February for the March - Now, if you disagree or you think -
DR. HUFF: No, I think so. Yes.
DR. COHN: But we should put it on for - I mean, let's hold that as an issue about what we want to do with that this year.
DR. HUFF: Yes.
DR. COHN: Judy.
DR. WARREN: So are you suggesting that to get ready for tomorrow's discussion that we go back and review what we had in the recommendation letter and what is in the - that little blurb that we got that Karen gave us of the law?
DR. COHN: Actually, no, I wasn't. Stan just brought it up.
DR. WARREN: (Laughter). I know that, but you made comments after that.
DR. COHN: Only because my observation is is that unless you all have a lot more time than I think you do, we are running out of time for the March letter, and so what I am saying, literally, is is that as we begin to finish off a letter that we intend to bring forward in March, we can sort of look at other important areas that we may want to deal with.
DR. WARREN: What I was thinking of is for the letter in March, we may want to address those issues as being future work like we did the last time.
DR. COHN: Okay. That is a reasonable - and that may be a very reasonable thing for us to frame, and I think your just saying that may have put it into something draft that Margret can remind us about. So is that - and that will at least remind us as we begin to look at letter about how we may and when we may want to handle those things.
DR. WARREN: Because the other thing is there was medication history in there as well as medical history, and I don't think we have touched that one either, have we?
MR. BLAIR: We touched medication history only from the standpoint of communicating it from PBM's to prescribers. There could be medication history from other sources, and we just didn't have time to go into all of those.
DR. COHN: You can take that as another possible area that we may want to further investigate.
I would suggest, though, that those other areas may be things that we may want to investigate, maybe not separately from medical history, because that stuff tends to overlap a bit.
Now, obviously, we have moved into next steps. I am concerned we actually haven't gotten this one handled - this step as opposed to the next steps.
Do others have other thoughts about what we have heard? I mean, certainly, I think the - I guess I would throw in the - which I know we were sort of taking notes on - what I thought were some very valuable conversations from NIST in terms of their reflections.
I mean, I think their model is an important model, personally. Others can reflect on whether they think it is an important model, but, once again, having - you know, the sense I think we all had looking at it initially was is that it was unclear the environments they were describing, where this applied, and I think hearing from NIST that there are - I mean, I use the term mitigating. They had different terms that they use to describe the environment and how it may be a factor in how one meets those various levels, I think, is an important thing for us to mull over or ponder over on how it may impact all of this.
While the NIST work is not really exactly a standard, certainly is a very useful framework for us to think about things, and, once again, may also relate to those buckets that we had talked about in terms of the types of data that get sent for e-prescribing. So just a thought there.
Other comments as we begin to wind down for the day?
Okay. What we'll try to do is tomorrow we are obviously going to be talking about HIPAA. I'm sure we'll spend the first part of the morning talking about HIPAA. We'll be having some subcommittee discussion in planning for next meetings. We are clearly on for February. I am sure some of that conversation tomorrow will be related to actually HIPAA and other administrative transaction, next steps for 2005, but we will, I think, come back and reflect on it, if there's other thoughts that you all have as you sleep on the information for today in terms of next steps.
Okay. Any final comments, questions?
Okay. With that, the meeting is adjourned, and we'll start up tomorrow morning at nine o'clock.
(Whereupon, the meeting adjourned at 5:21 p.m., to reconvene the following day.)