Transcript of the December 8, 2004 NCVHS Subcommittee on Standards and Security Hearing

This Transcript is Unedited

DEPARTMENT OF HEALTH AND HUMAN SERVICES

NATIONAL COMMITTEE ON VITAL AND HEALTH STATISTICS

Subcommittee on Standards and Security

December 8, 2004

Room 705A
Hubert H. Humphrey Building
200 Independence Avenue, SW
Washington, D.C. 20201

Proceedings By:
CASET Associates, Ltd.
10201 Lee Highway, Suite 160
Fairfax, Virginia 22030
(703) 352-0091

List of Participants:

Simon P. Cohn, M.D., Chair
Jeffrey S. Blair, MSA
Stan M. Huff, M.D.
Harry Reynolds
Judith Warren, Ph.D
Maria A. Friedman
Suzie Burke-Bebee
J. Michael Fitzmaurice, Ph.D
Marjorie Greenberg, M.D.
Rob Kolodner
Donna Pickett
Steve Steindel
Karen Trudel

Call To Order
Overview of E-Signature Process and Issues: Kepa Zubeldia
E-Signature: State Issues
- Carmen Catizone
- Eleni Anagnostiadis
- Mary Ryan
- Geff Brown
E-Signature: The Financial Services Perspective
- Jerry Buckley
E-Signature: The Network Perspective
- Richard Brook
- Teri Byrne
- Rick Ratliff
E-Signature: Health Care Perspective: SAFE/Pharma
- Ashley Evans
E-Signature: The Federal Perspective: Jeanette Thornton
Open Microphone

P R O C E E D I N G S (9:06 a.m.)

DR. COHN: Would everyone please be seated. We are going to be starting momentarily.

Good morning. I want to call this meeting to order. This is the first day of three days of hearings of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics. The committee is the main 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 Information Policy for Kaiser Permanente. I want to welcome fellow subcommittee members, HHS staff and others here in person, also welcome those listening in on the Internet. As always, I want to remind everyone to speak clearly and into the microphone during our hearings today and for the next two days.

Obviously we have a lot of work over the next three days. Before we go on and talk about the agenda, I want to take a moment and welcome Nathan Kolodny for joining us today. He is the new director of HIPAA standards in CMS. We really appreciate your participation, and we hope it will be the first of a number of upcoming subcommittees deliberations and sessions. So thank you.

I should comment for those who don’t know him, as I look through his CV, I read an interesting combination of law background, hospital administration CEO. It seems like a very good combination to be able to help us and the nation in our work as we move forward. So congratulations.

Today and tomorrow, the subcommittee continues our hearings on e-prescribing standards. As you all know, as part of the Medicare Modernization Act, the Secretary is required to adopt standards for e-prescribing, and NCVHS has been directed to develop such standards recommendations. We have already present ed a first set of recommendations, and I think as everyone know;s, we are now working on a second.

The focus for the next two days is on E-signature, which of course as we know is important for e-prescribing, but as those of us around the table and elsewhere know, it is also important for many other aspects of electronic, clinical and administrative activities. Indeed, many of you will remember that E-signature was one of the HIPAA standards that was supposed to be identified for schizophrenia.

Today we begin with an overview of our E-signature process and issues. We start off with Kepa Zubeldia. We are very pleased to have us come back and join us. As you all know, Kepa was a former member of the subcommittee and full committee, and is a recognized expert in this area. So thank you for joining us.

Following that, we have a discussion of state issues, and then from there we will move into discussions with the financial services area about their perspective, followed by a hearing from an industry collaboration called Secure Access for Everyone. Finally at the end of the afternoon or towards the end of the afternoon, we will hear from OMB on the federal perspective, and we are pleased that they are going to come and join us.

We want to thank Jeff Blair, our vice chair, for his help in moving forward this work plan, and of course, Maria Friedman for her great assistance in putting together the agenda for these next three days.

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 issues that we are discussing. And of course, we are going to have time at the end of the afternoon for brief comments by those in attendance. For those listening in on the Internet, we do welcome e-mails and letters on any of the issues coming before us over the next couple of days.

For those of you who are going to be on for the next couple of days, remember that tomorrow we will be hearing more testimony on E-signature. Those hearings start at 8:30 in the morning. Then on Friday we will be talking both about HIPAA as a HIPAA update, and we will also be hearing from the industry on progress related to some of the other work related to improving the e-prescribing standards, work that was recommended by NCVHS in its previous recommendations.

With that, let’s have introductions around the table and then around the room. For those of you on the committee and subcommittee, I would ask if as part of your introductions if you would indicate if there are any issues coming before us today for which you have conflicts of interest. Jeff?

MR. BLAIR: Jeff Blair, Medical Records Institute, vice chair of the subcommittee. I’m not aware of any conflicts of interest or anything I need to recuse myself from.

DR. STEINDEL: Steve Steindel, Centers for Disease Control and Prevention, staff to the subcommittee and liaison to the full committee.

DR. HUFF: Stan Huff, Intermountain Health Care and the University of Utah in Salt Lake City. I don’t know of any conflicts for this session.

DR. FITZMAURICE: Michael Fitzmaurice, Agency for Health Care Research and Quality, liaison to the committee and staff to the Subcommittee on Standards and Security.

PARTICIPANT: (Comments off mike.)

MS. TRUDEL: Karen Trudel, Centers for Medicare and Medicaid Services, staff to the subcommittee.

MS. PICKETT: Donna Pickett, National Center for Health Statistics, Centers for Disease Control and Prevention and staff to the subcommittee.

DR. ZUBELDIA: Kepa Zubeldia with Claredi Corporation.

MS. ANAGNOSTIADIS: Margaret Anagnostiadis, subcontractor to the subcommittee.

PARTICIPANT: (Comments off mike.)

DR. KOLODNY: Nathan Kolodny, Centers for Medicare and Medicaid Services.

DR. GREENBERG: Marjorie Greenberg, National Center for Health Statistics, CDC, and Executive Secretary to the committee.

MR. REYNOLDS: Harry Reynolds, Blue Cross Blue Shield of North Carolina and member of the committee, and no conflict.

DR. WARREN: Judy Warren, University of Kansas, member of the committee, and I don’t have any conflicts, either.

MS. FRIEDMAN: Maria Friedman, CMS and lead staff to the subcommittee.

(Whereupon, the remaining participant introductions were provided.)

DR. COHN: Welcome, everyone. I think with that, we will move into our first session. Kepa, welcome back, it is great seeing you again.

DR. ZUBELDIA: Thank you. Mr. Chairman, it is a privilege to be here, talking about electronic signatures and digital signatures.

I have prepared an overview of digital signatures, centering more on HIPAA than the e-prescribing act. But I think the topic is very generic, and except for a few HIPAA slides, it will apply to the rest of the work of the subcommittee.

I will be talking a little bit about the HIPAA statute and what the statute says about signatures. I will give you a PKI 301. It is a high level PKI, but it will go into a lot of detail in some of the things, so you understand the basic concepts behind digital signatures. I will talk about the difference between electronic and digital signatures, digital certificates, PKI standards that are applicable to signatures and signature standards.

The HIPAA law in Section 1173, there are several paragraphs. 1173A is the one that introduces the transaction standards. Then there is 1173E, that discusses electronic signature. Under 1173E, it says, the Secretary in coordination with the Secretary of Commerce shall adopt standards specifying procedures for the electronic submission and authentication of signatures with respect to transactions referred to in Subsection A1, which is HIPAA transactions. It is HIPAA transactions, including any future transactions the Secretary may adopt. Then 1183#-2 says, compliance with the standards adopted under paragraph one shall be deemed to satisfy federal and state statutory requirements for written signatures with respect to transactions referred to in Subsection A1, not for all commerce, but at least for those transactions.

So what does it mean when the law says, signatures for transmission and authentication of signatures? That is something that perhaps we can start addressing during this meeting.

Then it says, for the transactions in ll73A-1, none of which require a signature today, but in the future perhaps some claim attachments, which is a HIPAA transaction, may require signatures, for instance, contents, perhaps prescriptions as a claim attachment would require signatures. In the future, some new transactions may require signatures, perhaps prescriptions, e-prescribing. It is not part of HIPAA, but it could be one of the transactions that under HIPAA facilitates the implementation of electronic transmission of health information, whatever.

So here is some more food for thought. The HIPAA requirements for signatures are separate from the HIPAA security requirements. Why is that? Is the signature a proof of intent rather than a security mechanism? You know that a digital signature can be used as a security mechanism, but the signatures were separated in the HIPAA law. Is that because they have a separate intent meaning? We will talk a little bit more into that point.

If you think of signatures as the signature of an EDI file, a digital signature of an EDI file, what does it mean to sign an EDI file? Most of the time, the EDI content is obscure to the untrained eye. Sometimes it is obscure to the trained eye. So when you effect a digital signature on an 837 file with claims, is there a certain intent expressed by that signature? What is the intent? Is there a consent expressed by it, some sort of assertion? Or is it just a data integrity and security protection, a HIPAA security mechanism applied over one of the HIPAA EDI transactions.

If we look at a different aspect of signatures, electronic signatures, in June of 2000 was signed into law an act called the Electronic Signatures in Global and Electronic Commerce, a signed act. This is a very significant act, because it enables signatures nationally in all 50 states, and it defines an electronic signature as an electronic sound, symbol or process attached to or logically associated with a contract or other record, and executed or adopted by the person with the intent to sign the record.

The E-sign act passed in the summer of 2000, and also has provisions that allow electronic recordkeeping, and allows electronic signatures. The signatures under the E-sign act must have the intent to sign. Any electronic mark can be used. It doesn’t have to be a digital signature, any mark. It is technology independent, which is perceived to be a good characteristic for signatures, but because it is so open, it has the risk of using weak signature methods. I will show you some weak methods. However, it is simple to explain. It is very simple to understand when you apply an electronic signature to a document.

Let me give you an example. This is an example of an audio signature. Let’s see if the microphone can capture this. It is a legally valid signature to a consent to have my appendix removed. I say my name, I say what I want to happen, I agree to a specific form, I refer to the form, and that is my voice. You can tell it is my voice because of the accent. It would be very easy to forge that kind of voice signature with somebody that doesn’t have an accept as distinctive as mine. So it is a low technology, it is easy to understand, it is easy to capture with most PCs. Practically today all PCs have a microphone input. If they don’t have microphone, you can buy a microphone at Radio Shack for ten bucks and have a system capable of doing electronic signatures.

It is very weakly bound to the document. It is bound to the document in the sense that I refer to a specific form during the signature, but like I said, it is very easy to forge.

To give you another example of electronic signature that is also valid under the E-sign act, that is, the signature that you have seen — the UPS carriers carry a brown pad, and you sign in a little panel that is never big enough for the signature, and you manage to sign in that thing with the stylus they give you. A lot of stores use this kind of signature verification now for credit cards. According to the E-sign act, those are legally binding signatures. They are simple implementations. Again, it is a weak method. It would be easy to copy those signatures. In fact, you could phrase the signature and nobody would tell the difference in that electronic pad.

But electronic signatures don’t have to be weak. There is also strong technology available. It is called signature dynamics, where the signature is linked to the document in a way that creates a binding association that will not allow anybody else to copy that signature. It prevents duplication, and it can also use a digital certificate. Signatures that uses a digital certificate provides a very strong method of signing a document in a way that is easy to understand and a way that is simple to see what is happening there, and it is simple to represent.

Just for illustration purposes, I brought a picture of a very famous signature block. This is the Bill of Rights signature block, and you can see all the signers of the Bill of Rights with their characteristic signatures. The big one, John Hancock, is easy to recognize. You can see how each individual wrote their name in a different particular and personal way.

There is a long tradition of signing your name in a telegraphic way or in a personal way. If you look at some of these signatures, they are works of art. I am now showing the signature from some French documents. The French authorities are well known for their very beautiful signatures. Some of them would take ten minutes to duplicate, and some of them would take ten minutes to create de novo.

The signature dynamics capture these characteristics. Signature dynamics recognize that the signature is a two-dimensional object that is created along space and time, so it captures the X and Y coordinates along the time, so that tracing something is going to take longer than if you are actually signing de novo, but it also captures the pressure of the pen or the stylus, the velocity and the acceleration. So if you are not signing it exactly like the original signature, the signature dynamics are going to be different. You cannot fake a signature with exactly the same signature dynamics unless you have practiced a lot. But if you practiced a lot, you may be able to fake a signature with the same signature dynamics. Secretaries are known for faking their doctors’ signatures very well.

Signature dynamics are typically captured with a stylus and a digitizing pad. This is not the same kind of pad that you would use for a cursor on a PC or a laptop. It has to be defined resolution digitizing pad. So it is a special signature pad. And signature dynamics can be associated with a specific signed document though a hash. I am going to be talking more about hashes, but for now, let’s say that signature dynamics can be hashed, the document can be hashed, and they can be hashed together. So if the document changes, the signature is invalidated. You can use the signature as a security mechanism to detect alterations of the document.

But with signature dynamics, also the signer’s identity can be determined, although it would require forensics signature analysis, just like paper signatures. The advantage is that in signature dynamics, you know for a fact what is the pressure, the velocity, the acceleration, whereas in the paper signature, those are parameters that are estimated from the size of the tracing and other things that the forensics signature analyst can determine.

The signer’s identity can also be authenticated with a digital certificate issued by a certification authority, but is associated with that signature dynamics template. In practice, the way signature dynamics work is by using a template that reproduces the dynamics of the signature, XY coordinates, pressure, velocity, acceleration over time, and it is compared with the template that signature owner has registered with a system or with a certification entity, and if the templates match, then the signature is acceptable.

I have a graphic here that is showing the signature dynamics of John Hancock. Of course, this is all fake, but it has a nice template that can be compared with the registered template for that signature to determine whether it was the same or not.

Signature dynamics because of the E-sign act are legally binding in all 50 states and in some foreign countries. The IRS uses signature dynamics for tax forms in this country, and that is a very common application of the IRS. If you want to file an electronic tax form, you sign on this special signature dynamics pad, and that certifies that you signed your tax form with the IRS.

Signature dynamics is technology dependent. Each signature dynamics vendor has a proprietary system that is incompatible with each other. It is not that they are very interoperable; they are not interoperable. They are proprietary and compatible with each other. The leading vendors are Penop, Topaz and Cybersign. There are other vendors, but Penop, Topaz and Cybersign are the leading vendors in this country. Penop is a British vendor, Topaz is the one recommended by the National Notary Association, for what they call the electronic notary journal of material acts or something, that they recommend to capture signature dynamics and the fingerprint or the image of the person signing the electronic document. But even though the systems are relatively inexpensive and are in somewhat widespread use, they are not interoperable, so let me emphasize that again.

I have some examples of signed prescriptions, signed documents that are electronic prescriptions, with a signature captured wither with signature dynamics or with a simple graphical signature. This is a system that I am showing you on the screen that captures the signature electronically in the computer, captures the signature on a signature pad, and then when you click on the send button at the bottom of the screen, it sends the prescription with the signature via fax to the pharmacy. The pharmacies receive this as a faxed prescription, and they never know whether the signature was captured electronically or not.

The second example is an example from the National Health Care Service in Great Britain. It is an electronic prescription with a signature also captured with a signature dynamics pad that is reproduced on the screen or a paper printout electronically. But it was captured electronically, and at the end it is reproduced on paper.

Not all prescriptions are pharmacy prescriptions. There are some prescriptions that are — in this case, an ophthalmologist’s prescription for bifocals. Prescriptions like that would also benefit from electronic signatures. So I would urge the committee and subcommittee that when you look at signatures that are available from the E-sign act, that you keep in mind that there are other types of prescriptions, wheelchairs, that perhaps will benefit from electronic signatures, too.

HIPAA requires standards for the electronic transmission of signatures, standards for authentication of signatures for the HIPAA transactions. So let’s talk about signatures of other kinds. I am showing an example of something that I found in my archives from the mid-80s. HP came up with an instrument, an electronic instrument that they called a signature analyzer. It is the HP 5000-6A. They also have a 5000-4B. This signature analyzer is an electronic signature device, and the description in the catalog says that HP’s patented signature analysis technique enables the HP 5000-6A to generate a contrast four-digit fingerprint or signature of the digital data stream at a logic node. Any fault associated with the device connected through the node will force change in the data stream, and consequently produce an erroneous signature. This is to diagnose digital surface.

Why am I bringing this up? It is another from of electronic signature. That word signature or fingerprint is used in different contexts to mean different things. For instance, the GE jingle, We Bring Good Things to Life, you hear those musical notes, that is essentially an audio signature for GE. So what does the word signature really mean? They can be used for different things.

I am bringing this up because there is an artifact, electronic artifact, called a digital signature. I want to make a point of saying, why is this called a digital signature when it is not effected with the same kind of signature concept that I have been describing for the last ten, 15 minutes? It has noting to do with signing your name on a piece of paper, either with signature dynamics or with a pen.

In order to get into the digital signature, I am going to go through two or three aspects that will make up the digital signature. One is the message digest, the other is encryption with asymmetric keys, and then digital certificates. So bear with me; before we get to the end there is going to be some education and ramp-up process here.

What is a message digest? A message digest, also called a hash, is a one-way transformation of an entire message into a single number. There are different kinds of transformations into a single number. The simplest one is a check sum. A check sum would be a simple algorithm that produces a one bite check sum. It validates a short number. For instance, we are using check sums for the NPI. The last digit of the NPI is the check sum. You add up all the digits with a special algorithm and get a digit at the end that validates that the NPI has not been changed. Credit cards have check sums at the end. They have one digit at the end. The last digit of the credit card validates that the rest of the credit card digits have not been changed.

A CRC is a more complex type of check sum, and typically produces two or three bytes. This argues for little bit longer data streams, like PCPIP and SNA, to validate a buffer that is 1,000 bytes long or something. Instead of doing a check sum with a single digit, you do a check sum with two digits or three digits. That makes a more robust type of check sum.

Then there is something called a cryptographic hash that is a complex algorithm that produces 16 to 32 bytes of a check sum. This can be used to validate large amounts of data. Obviously, with a single byte check sum, there is only ten possibilities. With a two byte check sum, there is only 256 possibilities. If you are going to validate a Library of Congress, and the entire Library of Congress has to be validated to make sure it hasn’t been tampered with, you are going to rely on something that offers more than 356 possibilities. So to validate large amounts of data such as an image or a Microsoft Word document or a Power Point or something like that, that, you would use a cryptographic hash.

Before I go on to the next slide, let me give you a couple of examples of what is a hash. The definition says a one-way transformation. One-way transformation means a transformation that cannot be reversed. Perhaps one of the appropriate comparisons is with a potato. If you make hash browns, you are shredding the potato into little pieces, to the point that you cannot build the potato again out of the little pieces. But those little pieces are a representation of the original potato.

Another example is if you break a plate. You take a plate and you break it into a thousand little pieces; you cannot build that plate again out of the little pieces. In my house, we do. But a bad example would be a watch. If you take a watch and disassemble it into pieces, it would be possible to rebuilt the watch out of the little pieces if you had the right instructions to do so. So a hash is a transformation that is a one-way transformation that cannot be reversed.

Some of the properties of a hash is that any change in the original data stream is going to produce a different hash. Any single change in the original data stream is going to produce a different hash. So each data stream will be one unique hash. If the hash is different, it is because the data stream was different. Transformation cannot be reversed. You cannot obtain the original data from the hash. The changes are not predictable. You cannot predict, given a data set, what the hash will be for that data set. This is a theoretical hash, but in reality, most of the time you will find that hashes do not produce coalitions. No two messages will give the same hash, and there is billions and trillions of possible hashes. So the key message is, if they have a different hash, it is because they are different messages. You cannot mathematically predict two messages that will produce the same hash.

The algorithm to create the hash is well known. Topically we use MD5 or SHAL-1 algorithms, although there are other algorithms. But with a well-known algorithm, if i produce a hash of a Power Point file and you use the same algorithm, you are going to come up with exactly the same hash. But given that hash, I cannot tell how to change a file to make it match a hash that has been produced.

I have some examples of MD-5 hashes. If you were to hash the sentence, this is an example of MD-5, just those words, it would produce that number that begins with sig 090. You change one word or one letter or one anything in that sentence, the hash will be completely different, not just one or two bytes different, completely different. In fact, the length of the hash is constant, so even for a very short sentence, even just the word “this”, it produces a full-sized hash and every single word, even the letter A, produces a full-sized hash. Given that hash, I can’t tell that that hash came from the letter A. There is no way to predict that.

If I was to hash the entire HIPAA law, H.L. 3103, in PDF form, I would get that other hash that is there. So you can see that the length of the hash is constant, and it is a hexadecimal number with letters and digits. But it is just a number that is dependent on the content of the hashed text or the hashed data, and of constant length.

The process is, I can take a document, it could be a prescription, it could be electronic medical records, it could be an Xray, it could be a PDF, it could be a piece of text in between XML tags. It doesn’t have to be an entire document. I can take some text or something, an electronic byte stream, and with a message digest calculate a hash. That message digest can then be attached to the document, and this is a particular application for document validation, and I can take the hash of the document, attach it to the document, and give it to somebody that could then take the same document, calculate the hash again by themselves, using the same algorithm, compare the hash that I gave them, and if the two match, they know that the document has not been tampered with while in transit, because the hash that they calculated is exactly the same hash I gave them when I produced the document. If the hashes don’t match, either the document or the hash has been tampered with.

Of course, if I give a hash and a document on the clear, anybody could change the document, build a new hash and substitute the old one with a new one. So it is not a lot of protection, but if I have a mechanism to say, this is a document, this is the hash, somebody else can verify, this is better than nothing. But remember, the capability here that I am expressing is to create a hash and attach the hash to a document. I will use that later.

So the concept here is that the message digest is a fingerprint of the document. Any changes in the document will result in a different hash. The hash doesn’t prevent changes in a document, it detects the changes. It helps preserve the integrity of the document and acts as a tamper-evident seal.

Remember the Tylenol tampering that occurred in the mid-80s, and how it changed the way pharmaceutical products are packaged and distributed? That doesn’t mean that the little transparent seal around the neck of the Tylenol bottles is going to prevent anybody from breaking the seal. My children can break that seal all the time. They love to do that. But once the seal is broken, then you can detect that the seal has been broken. So it doesn’t prevent tempering, but it does detect that something happened. That is the concept.

Now let’s switch to another concept that we are going to be using for digital signatures, and that is asymmetric encryption. Symmetric encryption is a special kind of encryption where each trading partner, each party that participates in the encryption, has a key pair. One of the keys of the pair can reverse the encryption operation of the other key. One key is made available to the public, the other key is private, and one key cannot be derived from the other key. So if I make my public key available to you, from my public key you cannot tell what my private key is.

This has lots of advantages. One key payor is used by entity, it scales linearly, there are all kinds of benefits. We won’t go into that. Encryption and decryption with asymmetric algorithms is very slow, and it is only usable for short data sets because it is so slow.

How does this all fit into signatures? We will get into that in a minute. The concept of asymmetric encryption is that I can take a key payor and encrypt something with one half of the key payor. I am going to cal it in this case the encryption key. Then I can use the other half to decrypt it. I cannot use the encryption key to decrypt, I have to use the other half of the key, the decryption half, to decrypt it.

The matching pair of keys is unique. Knowing one key doesn’t give any information about the other key, and one key in the pair can be published. So let’s say that I publish my decryption half of the key payor of the world, and you all have aces to my decryption key. You don’t have access to my encryption key, but you have access to my decryption key. Only I have the encryption key that corresponds to that, and I keep that as a closely guarded secret.

Now, if I was to encrypt anything, I could not decrypt it, because I don’t have the decryption key. But you have it, so you could decrypt something. What that will tell you is that I must have been the one that encrypted whatever it was, because I am the only one that has that encryption key. It doesn’t protect the document, but it gives you the assurance that I am the only one that has the encryption key, and if you can decrypt it, it must have been encrypted by me. Does that make sense?

So in this asymmetric encryption process, instead of encrypting the document itself, if I was to encrypt the hash, we would get something completely different from encryption. So if you put those two concepts together, message digest and the asymmetric encryption, and I encrypt the hash, what do I get? I get a digital signature.

Let me explain how this works. I have a document. I calculate the hash of the document, and I encrypt that hash with my secret key. Then I attach that encrypted hash to the document. Instead of attaching the original hash like I was doing before, now I am attaching that encrypted hash that I have encrypted to the document. Only I could have encrypted that hash with my secret key. Nobody else has my secret key. So you will be able to verify that it was me that encrypted different hash.

Remember that I said before that anybody could take the document, change the document and create a new hash and send the document with a new hash and you won’t tell the difference? Now as it turns out, if I am the only one that can encrypt the hash that way, nobody else can encrypt the hash that way because nobody else has my secret key, nobody can alter the document and replace the hash at the same time, because they don’t have access to my private key.

So the process for digital signatures is that I calculate the hash of a secret file or document to be signed, or part of the document, if only that part is to be signed. For instance, HL-7 version there has tags in XML that says, to be signed. They surround the part of the HL=7 message that is going to be signed. You don’t have to sign the entire HL=7 message, you only sign part of it. When you surround that with the tags, only the part that is surrounded by the tags will be calculated into the hash. Then I encrypt the hash with my private key and that produces a digital signature. It is the combination of the hash of the document or part of the document and a secret that only I possess. Then I attach the digital signature to the document. When the receiver receives this document, let’s say you receive the document, you detach the digital signature and you decrypt my digital signature with the public key that I gave you. You all have my public key, and you can decrypt that digital signature, and you are going to obtain the hash that I originally encrypted. You can calculate the hash of the message yourself, and if the hash that you calculated yourself and the hash that I gave you under that encrypted payload, then you know for certain that the document had not been changed and that I was the one that encrypted that hash originally. Therefore, that is my digital signature for that document.

So the verification process works like this. You detach the digital signature, you decrypt the digital signature with the public key of the signer which you have, it is public, and that presumes that you know who the signer is and that you have access to that public key, You calculate by yourself the hash of the document and you match the hash that you calculated with the one obtained from the digital signature for that document. If the match is good, that is a good signature. If the match is bad, either the document was tampered with or the secret key is not the key that had encrypted that payload, which could happen. Somebody else gets the document, they calculate the hash and they put their signature on it. It won’t decrypt with my public key, it will decrypt with their public key. So when you decrypt it with my public key it won’t decrypt correctly and the hashes won’t match. So that gives you an invalid signature.

This is a couple of examples of signed documents. This is a signature effected with a program called PGP or also GPG. This is an Internet standard signature. It has a couple of tags that say, begin the PGP signed message and begin the PGP signature. So only the text within those tags has been signed, and then you have the signature at the bottom, and it looks like three and a half lines worth of what seems to be random characters. That is in fact the hash of that message signed with a particular secret key.

This is another example of a similar message signed with a different type of signature. This is called an S/MIME signature instead of a PGP signature. The message looks the same. There is the MIME boundaries, in this case the entire MIMES object or the MIME body part is signed, and then it looks like there is a lot more of that cryptographic text at the bottom, that has that signature, in fact, a lot more of that text. We have almost two screenfuls of that text. The reason for that is because in that encrypted or seemingly encrypted text, it is not only the signature, but also the digital signature of the signer. So when this MIME message is distributed, not only the message is sent, the signature is sent and the digital certificate is sent along with the signature. That is the standard way of distributing MIME messages. On the PGP, the certification is never distributed along with the signature. The signature goes by itself.

Remember how under HIPAA we had a requirement for standards specifying procedures for an electronic submission of the signature? That is another part that we haven’t talked about. One is very long with the certification, the other is very short with the digital signature only. There are intermediate ways of sending those examples. There are other standards for sending signatures.

Where is the industry in all this? For digital signatures, there is a variety of hashing algorithms. The most common ones are MD-5 and SHA-1. There is a good number of other algorithms that are used in other products. N-hash, MD-2, MD-4, SHA, RIPE-MD, that is used in Europe, GOST is used in the Soviet Union. MD-2 and MD-4 have been broken, have been proven to be not as strong encryption or hashing algorithms as MD-5 or SHA-1.

There is also a variety of encryption algorithms. Remember, a signature has at least two parts. It has a hash and then an encryption, so the encryption can be done with a variety of encryption algorithms. Typically RSA and DSA are the most common. VSA is the U.S. government standard for signature. But in the last few years, there have been additional standard encryption algorithms that have been very, very used, especially ElGamal and Elliptic Curve, although there are other standards.

There is also a variety of encryption sizes. The recommendation for RSA or DSA is to use at least 1,048 bits for the encryption key, although there are some people that are saying that it is better encryption keys with 4,000 bits or even 8,000 bits for some of the very strong signatures.

There is also a variety of ways to encode the signature. Remember, a signature is nothing more than a series of binary bytes that represent an encrypted hash. That can be typically represented either in Abstract Syntax Notation 1, ASN 1, or PGP. Those are the most common methods. Typically, ASN 1 and PGP use base 64 encoding.

There is also a possibility of still using ASN 1 or PGP to use XML or even proprietary encodings to encode the signature. Then there is a variety of options for the data content that is included in the signature. Obviously the signature has to have a hash, and has to have an encrypted version of the hash, not just the hash. But sometimes not only the document is hashed, but we have the document hash and a time stamp, when was this document signed. Sometimes there are signature indicators that say, this is a high security signature or this is a routine initials type of signature, or this is a non-security signature, or this signature is intended to be a legal contract, or this signature is not intended to be a legal contract. That kind of indication is sometimes included in the signature as additional attributes of the signature, and the way to encode those attributes is not standard. Sometimes the digital certificate is included in the signature.

Where is the commercial availability of these products? Most electronic mail software packages can digitally sign the entire message, one way or the other. Some packages can also sign attachments. Outlook Express can sign messages. A lot of the commercial e-mail packages can sign messages. Very few of them — in fact, I don’t know any e-mail package that can sign a part of a message. They will sign either the entire message or the message and the attachments, but I don’t know of anybody that can sign part of a message. The way to do that could be perhaps PGP, but that is not an e-mail signing package, it is just plain text signing package.

There is also other software that is for non-e-mail that implements signature. Adobe Acrobat has a way to sign the documents, and you can verify the signature. PGP, GPG; EK Zip has a version of electronically signed compressed archives. Microsoft distributes some objects, and some of their software is distributed with electronic signatures. You probably have all seen that popup box that says, this object that you are about to download has been signed by so-and-so, do you want to trust this signature, click her yes, click no, stop the downloading, click here to get a virus.

There is also JAVA beans signed electronically. X12 implements digital signature of the entire transaction set as part of the expert syntax itself. So you can send an expert transaction set signed or not signed, encrypted or not encrypted, signed and encrypted, if you want. It is the entire transaction set, it is not part of a transaction set.

HL-7 version three has XML signature and authentication times that indicate the parts to be signed, and you can specify what are the parts of the HL-7 documents that are going to be signed, and only sign that part. This also allows multiple signatures in the document, and it allows counter signatures, the signature of a signature, which is a very possible thing.

But the interoperability of all of these signature methods is the problem, because they are different, and there is no interoperability among them. Even with the electronic mail software packages, there is no guaranteed interoperability, that if I send you a signed message, signed with Outlook, that your e-mail package would be able to verify that signature.

When you go to verify a document, there is a concept of authentication. I want to break this authentication concept into three different types of authentication. There is the signature authentication. Was the signature written by this person? You go to court and the judge will ask, is this your signature, just to authenticate that you did in fact sign that document. Then there is document authentication, is this the document you signed, because as we all know, a signature on a paper does not protect the paper from being changed. The paper could have been changed, previous pages of documents could have been changed, and then you are shown a document, and that is not what you signed. The signature page is yours, the rest of the document is not.

Then there is entity authentication; is this signer the person who he claims to be. Am I Kepa Zubeldia? How do you know? So that is a very interesting and challenging problem.

These three concepts are deeply interrelated. When we talk about authentication, a lot of times we don’t consciously make the distinction between those three concepts.

HIPAA has a requirement for specifying procedures for electronic authentication of a signature. In the HIPAA statute, it said, the Secretary in coordination with the Secretary of Commerce shal adopt standards specifying procedures for the electronic transmission and authentication of signatures with respect to transactions occurring through Subsection A1. It doesn’t say authentication of the signer. It doesn’t say authentication of the document. It says authentication of the signature.

So what does it mean to authenticate a signature and we don’t authenticate the context? Who is the signer of a signature? What is the document being signed? What was the intent of the signature? When was it signed? Does it make any sense to authenticate a signature without authenticating the context of the signature? I’m not bringing answers, I’m just bringing questions.

In the traditional signature authentication process, there are several ways to authenticate a signature. You can authenticate a signature through a witnessing of the signature process and personal knowledge. Witness signature, for instance, when you are required to sign a document in front of a state, federal or other officer. You are probably familiar with requirements to sign a document in front of a federal officer. That has to be a witness signature. Notary publics, their profession is to witness signatures.

Another method of authentication is through signature cards. The banks are supposed to use signature cards. At least they capture your signature on a card when you open an account. I don’t know if they ever use it after that, but at least they capture the signature, and if they need to use the card, they will use it after that.

Sometimes the signature are authenticated through an established record. When you are practicing medicine and you are sending routinely prescriptions to a pharmacy, the pharmacist gets to know your signature. They don’t have a signature card. You probably have never signed in front of the pharmacist, but through a series of prescriptions in the health care context, they know that that is in fact your signature.

Sometimes the business contact establishes the signature and the authentication of the signature. For instance, there is banking regulations that says who can sign a check and how the check has to be signed, and commerce law that regulates contracts, that regulates these kind of business transactions. Sometimes you don’t even need a signature on a piece of paper, just a trail of e-mails agreeing to a transaction, and at the end you send an e-mail that says that if this is okay with you and this is your e-mail, and all of these e-mails agreeing to a transaction have become a paper trail if you want, all electronic, but an electronic paper trail, with your e-mail address and agreement, that is enough in commerce to establish a context and create an authentic binding transaction.

But sometimes, those methods fail and the courts have to resort to expert witnesses to authenticate a signature. There are people who do that for a living. They act as expert authenticators of a written signature.

So if we look at authentication technology for signature dynamics and for digital signatures, we could compare the signature dynamics with a registered template, similar to comparing the signature with a bank signature card. These signature dynamics is not a perfect comparison, because when you repeat the signatures, they are not going to be exactly the same, same type, same pressure, same velocity, same everything. So it will be an approximately comparison, so it has to be done by an expert, by a forensic signature dynamics expert. It is not a computerized comparison. In fact, the signature dynamics validation software has a percentage of errors, because the comparisons are not always perfect. But it approaches, in fact, it is better than the signatures compared by a forensic expert on a piece of paper.

The template on the signature dynamics against which the signature is compared, that template can be certified by a certification authority. We will get into that in a minute.

The authentication for digital signatures, because it is a mathematically derived hash that has to be encrypted with an exact encryption algorithm, can be compared with a public key, with an exact comparison by a program. So the key can be certified by a certification authority, and I can have absolute certainty that the hash was encrypted with a specific private key that corresponds to the key in the certification issued by a certification authority.

Certification authority is a concept that I need to get into a little more detail, on how this works, because it is used extensively when we talk about digital signatures, and I think we need to discuss a little bit more what it is.

A certification authority is a third party authenticator. It authenticates something. Third party, meaning it is not either the signer or the verifier of the signature, somebody else that is not involved in that transaction, either the signer or the verifier.

Typically, the certification authority is going to issue a certificate — we call them digital certificates — that expresses what is it the certification authority is certifying. The certifications will contain two components. One is the public key of the encryption half, the public key that belongs to the signer, or a template or signature dynamics, and the second component is typically a combination of the legal name of the signer, perhaps an e-mail address of the signer, validity dates of the certification, and certain other attributes of the signer. That component of attributes is variable. It could have things like a DEA number, and the digital certificate could contain not only your public key and your name, but also your DEA number, or access privileges or the clearance that you have, or some signature privileges. This signature is to be used for legal contracts, this signature is not to be used for legal contracts. Things that you specify along with your encryption or decryption public key, you specify some things.

You could have biometric. You could have a picture, a fingerprint, a retinal scan. All of these things are things that the certification authority is going to certify as belonging to the individual identified in the certification.

There is what is called certification extensions. A digital certificate can contain any number of things. If you think that the X12 standards and the HL-7 standards have a variety of things that can be inside the standard, digital certificates have even more variety. You can put anything you want inside a digital certificate.

Here is how the digital certificates work, how they are created. Let’s say that you have encryption software. Let’s say you have Internet Explorer or web browser as your encryption software, or Outlook. All of these products have encryption technology built into the product. You use your encryption software to create your key payor. Your key payor has two parts. It has your private key that you are going to keep secret forever, and it has a public key that you are going to distribute to the world. With that encryption software, you create your key payor, and then you send a message to a certification authority saying, here is who I am, I am Kepa Zubeldia from ABC Corporation, U.S. My e-mail is kepazubeldia.com. I want a certification valid from 11/18/04 to 11/18/05. Here is my public key. I send that information to a certification authority.

The first thing the certification authority wants to know is, do I in fact have the private key that corresponds to this public key, or have I taken somebody else’s public key and attached it to the message as if it was mine. So the first thing they ask me to do is, would you please sign that message with your private key? Now I can sign that message saying, this is who I am and this is my public key. I can sign that with my private key. Only I have my private key. So when the certification authority gets that signed certification request, they verify that it was signed by my private key, and that the signature matches with the public key that was in the certification request. So they know for sure that I have the private key that corresponds to that public key I am trying to certify.

Now that certification authority has my identity block that says, I am Kepa Zubeldia, I work for ABC Corporation, and this is my information. They have my public key. Then the certification authority is going to calculate a hash, a message digest with that combination, my identity and my public key, and they are going to encrypt that hash with the certification authority’s private key, not my key, but the certification authority’s private key. In essence, the certification authority is signing my certification, and my certification, all it is, is my public key and my identity.

I am saying public key; I could have attached my signature template to a certification instead. I could have said, certification authority, this is my signature template, and this is my identity, would you please sign this with your digital signature. I could have attached my picture to a certification, and of course, the certification authority would then have to require my physical presence to see that my picture matches me. So that is a little more complex process.

But I can attach anything I want to a digital certificate. In essence, I am asking a third party to verify that my identity is who the identity of a certification says it is, and that my public key or my picture or my signature dynamics or whatever else I want to include in the certification is true and correct. The certification authority is going to essentially create a digital signature of whatever I am asking them to certify. Of course, they verify that I am who I claim to be and that I have a private key or that I have a signature dynamics by making me sign in front of them, or that that picture is mine by looking at me.

That is called a digital certificate. I have the identity of the individual, and either the public key or the signature dynamics or the picture or whatever I want certified and signed by a third party. That third party is called a certification authority, because they are signing with their private key something that they are certifying is true and correct. That is called a digital certificate.

So my digital certificate is then produced by the certification authority, typically encoded in ASN 1 as a X.509 certificate, PGP certificate or XML certificate. A digital certificate binds the identity of the individual with a public key or a signature dynamics template. It authenticates the owner of a public key or of a signature dynamics template. It is a conveyor, it is a mechanism to transmit a public key or the signature dynamics template. It is a secure mechanism, because you know that if anybody tampers with the contents of the certificate, the signature of the certificate issued by the certification authority will be invalidated. It is issued by a trusted third party, a certification authority, and it could be revoked by the certification authority, for instance, if the certification authority finds that I lost my private key, somebody else stole my private key, the certification authority can revoke the certificate and say, this certificate should no longer be considered valid, it is untrusted at this point.

What is the difference between digital certificates and digital signatures? The digital certificate attests to the identity of the owner of the encryption key or the signature dynamics template. It is issued by the certification authority. A digital signature protects or verifies a file or an e-mail against tempering and identifies the signer, and it is issued by the owner of the signed document, not by a third party, but by the owner of the signed document. Owner not in a literal way. If I sign a prescription, I am not the owner of the prescription, I am just the signer of the prescription.

So the certification authority validates the identity o the signer, and the digital signature validates the document itself. Two completely different concepts. A digital signature is in fact nothing but a particular expression of one kind of digital signature. It is a digital signature of a certification authority signing some cryptographic material or signing a signature template.

The signed material is included inside the digital certificate. The cryptographic key, my public key, is included inside the digital certificate, or the signature dynamics template is included inside the digital certificate. It is singed by a third party certification authority, although there are also self signed certificates, where I can say, this is my digital signature, this is my public key, this is my identity, this is my electronic signature template, and I sign it myself.

The value of that is not all that great, other than to know that I can give you my digital signature and you can verify that it hasn’t been tampered with. So if the interest is in authenticating an individual and you know me, and I give you my signature, you don’t need to authenticate my signature, you already know me. All you need to do is make sure the signature hasn’t been corrupted in the process.

This is used very commonly by employers when they give a digital signature to employees. The employer knows the employees, and they say, here is your certificate. Sometimes there is not a need for a third party to be a digital signer. This is also used by PCP signatures a lot, where I create my own PGP certificate and I give it to you, and if you know me, then you can trust my PGP certificate.

There is well-defined and universally used digital signature standard formats. You know that standard formats are good, but the implementation is the trick, right?

Everybody uses the X12 509 certificates for digital signatures. About five years ago, PGP started using X 509 certificates for digital signatures also. Everybody uses X 509-D3. But there is a variety of certificate extensions. Certificate extensions is just like the implementation of standards that we are familiar with. You can put anything you want in a certificate extension. So those certificate extensions make the certificates non-standard from implementation to implementation.

In a digital signature, they sign material. The previous slide was about digital certificates. Now I am going to talk about digital signatures, of which digital certificates are a particular case. This is the generic digital signature. The signed material is totally variable. In a digital certificate, the signed material was a cryptographic key or a signature dynamics template or a picture or a biometric of some sort.

In a digital signature, the signed material could be an entire text file, a PDF, a digital image, an XML-X, HL-7 tag that says, this is what has to be signed, an EDI transaction or part of an EDI transaction. The signed material is variable.

The signature and signed material relationship can vary from one signature to another. For instance, you can package the signed material as one file along with the signature, just like the certificates do, and you can send a signature inside the document. HL-7 does that. HL-7 will send the signature inside an HL-7 document. So inside the HL-7 document, you will have some tags that say, this is to be signed, these tags, and then some tags below that that says, this is the signature of the immediately preceding signed block, and then the HL-7 document continues. You can have multiple signed sections in an HL-7 document. In fact, one of the to be signed sections could contain other signed parts and other signatures, because you can sign anything you want.

So the signature can be packaged inside the document, or the document can be packaged inside the signature, just like certificates. The certificate package is the payload, which is the cryptographic key inside the certificate. So you can wrap one inside the other, and there are different ways to doing it.

They can also be packaged as separate files. PGP will allow you to put the signature together with a document or as a separate file. What is the use of a separate file? If I sign a Power Point document with PGP, I can give you the Power Point document as one file and the signature of the Power Point document as a separate file. You can still validate that signature against the Power Point document. That signature only contains the encrypted hash, right? You can still validate the signature against the Power Point document. But you can also use the Power Point document as is without validating the signature, just by using Microsoft Power Point, if you don’t have the software to validate the signature. Whereas, if I give you one document that includes the Power Point presentation with the signature and you don’t have the software to validate the signature, you are stuck, because you can’t use the Power Point. So there are advantages and disadvantages both ways. Of course, there is no standard way to do it. It is being done today both ways.

Also, the relationship between the signature and the certificate varies. In some cases, the certificate is sent with each signature. Every time I sign something, I include the digital certificate from the certification authority. So you can validate my certificate even if you are not connected to the Internet. You can validate it right away, and you can validate my signature.

In other cases, I will only send the signature, and you have to retrieve the certificate. The first time you get my signature, you have to retrieve the signature from a repository somewhere on the Internet. You go retrieve the certificate, and from that point on, you keep a copy of the certificate and you can validate my signature. That makes for smaller signatures, and it is being used both ways. Sometimes you send the signature and the certificate, and sometimes you only send the signature.

There are standards for all of this. It is the implementation that varies. In signature encoding, there is no dominant standard to encode the signature. Remember, there is a standard for certificates. The certificates always include the signed material inside the certificate, but for signatures there is no standard. There is signatures encoded in proprietary ways, using Abstract Syntax Notation 1, or XML. HL-7 is using XML signatures. PGP uses different standards for employing the signature. S/MIME uses different ways for encoding the signature. So there are different ways to encode the signature, depending on what is the particular application. The signature for a digital certificate is going to be using the X 509-D3, the standard for encoding the signature, because it is a signature for a certificate. If the signature is for an HL-7 document, the signature is going to be encoded in XML, used in XML tags, perhaps using ASN 1, perhaps not, and using base 64 encoding because XML likes to do base 64 encoding. But if the signature is going to be signing the document and is going to be kept separate from the document, perhaps you are using PGP or some other way of sending the signature separate from the document. So there is really not one standard that you can use for signatures. Depending on what the use is, there will be one standard that is more applicable than others.

So the industry over the last few years has made a little bit of progress in this. I’ll say just a little bit of progress, because we were expecting a lot more progress, and there hasn’t been a lot of progress.

Certification authorities. About five, six years ago there were maybe 20 certification authorities. Through a process of mergers and acquisitions and bankruptcies, the number has gone down, and now there is about four or five dominant certification authorities, with probably the dominant certification authority being Verisign.

The U.S. government is also issuing certificates for the military and for other parts of the government, so it is a substantial certification authority. In fact, because different departments are issuing certificates for different uses, the U.S. government started about four or five years ago a project that created bridge certification authorities, that would allow all the government certification authorities to connect to each other, and to trade certificate paths, so you can validate the certification from one certification authority, even if your operations operate under a different department that use a different certification authority. That federal PKI bridge I understand is operational, but there hasn’t been a lot of progress made in it lately.

There was some intention of incorporating into the PKI bridge some of the commercial sector, and I understand there is not a lot of progress there. However, I would encourage the subcommittee to get in contact with Richard Wieder of the Department of the Treasury, which was chairing the federal PKI bridge, and perhaps he can bring a more recent status on where that project is.

There are also standards, or a lot of work still being done on a certification policies document that rules the operations of a certification authority and says, these are the policies and procedures that we use to authenticate the individuals. These are the procedures we use for our certification authority operations, how we preserve the certification authority private key, what will we do if the certification authority private key is destroyed, what are the rules for requesting the revocation of a certificate or requesting a certificate, what certificate extensions we use. All of that is defined by certification policies.

The American Bar Association has defined — and this is not bars, this is lawyers — has defined certification policies for digital signatures. They have incorporated requirements in some states for certification authorities to be registered and regulated by the state, and register their certification policies with the state. There are several states that have regulations for this.

Then there are a couple of different standards for certification revocation. The certification authorities were issuing certificate revocation lists, that list certificates that have been revoked before their expiration date. Those lists are substantially large if you go to one of the large certification authorities like Verisign. They can get into megabytes, and you will have to download that entire certification revocation list every time you want to refresh it, so it is not particular efficient.

There is another standard called OCSP that allows you to retrieve a certification validity online, and ask the certification authority, is this certificate valid now, and they will say yes or no. Of course, you have to be connected to the Internet at that point to do that request, but then you can verify that the certificate hasn’t been revoked. It is the same process that we saw with the credit cards. Twenty years ago, the credit cards issued stop booklets. You had a little booklet, and they had to look up the credit card number. They issued the booklets once a week or once a month. Now the credit card verification is all done online real time, so the booklets are gone.

Certification extensions. There has been some substantial progress for certificate extensions for health care. The ASTM has some E-31 standards for certificate extensions. I understand the ASTM will be testifying before the subcommittee in the next couple of days. So perhaps they can bring what they have done. They have done a lot of work for certificate extensions especially to encode attributes in the certificate, to say these are the attributes of interest in health care.

Again, these are certificates that are for digital signatures. I don’t think that the ASTM certificates have been extended to include signature dynamics yet.

There are certificate extensions in other industries that are used for other uses, and define certificate extensions used by websites, electronic commerce websites. When you go to amazon.com to buy something, you go into a secure website; their certificate has been issued by a certification authority, and they have as a certificate extension the URL of www.amazon.com. That kind of information is included in the certificate. That kind of information probably would not be appropriate for a physician that doesn’t maintain his own website. You are not going to have that kind of extension. So you can see the variety there.

Then in the software side, digital certificates, digital signatures, certificate revocation has become embedded in the software. Microsoft, Sun, Adobe, all the major software packages, for software distribution, they are signing the software to make sure it doesn’t contain virus and worms. It is built into the browsers. Practically all the web browsers today include SSL extensions that include certificates. It is built into all kinds of software for both signature and encryption.

Problems with all this. Interoperability is the first problem. There are no standards for digital or electronic signatures in universal use. There are standards for digital certificates, which is one particular type of signature. There is no standard for signatures themselves.

Even in the case of certificates where there is a standard for certificates, there are interoperability problems, because the extensions are not always used the same way. So there is very good interoperability of the certificates themselves; it is certificate extensions that are sometimes just ignored by the software. If the certificate contains something you don’t know, just ignore it. That extension could be critical. If the certificate says that this certificate is not to be used for signatures for commerce, and the software ignores that extension because the software has not implemented the extension, the software is not going to give you any warnings. It is routine to ignore extensions, and you don’t know that the certificate was not supposed to be used for signatures. So that is a little bit of a problem.

Certification authority interoperability. The PKI bridge is working on that. In the meantime, there is cross certification. Most of the software packages will include the root certificates for multiple certification authorities, so that is not a big problem anymore.

The technology is complex. The deployment has been much slower than originally predicted. We thought that by now, everybody should have one or two certificates that they use on a routine basis, and that is not the case. Even the AMA has been trying to distribute three digital certificates to all the physicians in the country, and i believe they will be coming here tomorrow — no? Well, their digital certificate, the AMA I.D., I think it is called, Web I.D., or something, the success has been almost nil. There are very few people that have the certificate, and the applications to use the certificate are non-existent.

The FDA has been talking about certificates. The DEA has a project using digital certificates and digital signatures. I think they were doing a final project in Baltimore and in the VA. The VA was going to be issuing digital certificates to every prescriber that has a DEA number, and also digital certificates for pharmacies so they can reorder in the electronic 222 form, and I will let them report where they are.

PKI benefits. I am trying to wrap up here. PKI has lots of benefits. PKI is a public key infrastructure. It is a distribution of electronic keys and digital certificates that enable this kind of technology to happen. This kind of technology can help with the increasing trust in electronic transactions Perhaps one day we will be able to trust the Internet as much as we trust face to face transactions. Some of us already trust the Internet, by the way, but perhaps others will. I’m not looking at anybody.

The certificates can be used for distribution of signature and encryption keys. They enable secure transactions over the Internet. The certificate and key management are simplified if there is a standard that everybody uses. But we go back to the same concept that drives the HIPAA transactions. If there is a standard, everybody uses the same standard, it simplifies the process, reduces the cost of certificates, exactly the same drivers that were driving the HIPAA transactions or not driving the HIPAA transactions are driving or not driving PKI. It is exactly the same problem. The issues are almost the same, too.

The best interoperable results in PKI are produced by vendor solutions. If you go to an In-Trust system, In-trust will sell you a single vendor solution that works great, but only works for In-Trust products. You go to Novaell, and they have a solution that works great. Some of the solutions claim compatibility with other products, and some to a large extent deliver on that compatibility, but there is not universal compatibility.

Certificate maintenance is expensive. This is a problem that has come up in the last two or three years. As the software to become a certification authority becomes more widely available, some entities are saying, I know my trading partners better than the CA. Why would I want a CA, third party, issue a certificate at a cost when I can issue them myself? Especially some payors are saying, you want to do electronic transactions with me, I’ll give you a digital certificate that can insure the transactions over the Internet, because I know who you are. You are my provider, you have a contract with me. You are sending things to me every day. I am doing business with you every day. I can issue you a certificate, no cost, and you can do business with me.

The problem is that that provider is going to need a certificate with every payor, so the advantage of the PKI of having one key which is my key, and I use my key with everybody I do business with, disappears. Now I need to have a key for every single payor. That just doesn’t work.

So let’s say that we establish a PKI, and you all have a certificate. That would be great. Now what do you do with it? After you have a certificate, we have to have standards for signatures, standards for encryption, standards for single sign-on, and all these other wonderful uses for the certificate. Even though there is a standard for certificates, X 509-D3, we still don’t have standards for everything else. So without those standards, we can’t use the certificate, which is one of the problems this subcommittee is about to resolve.

So going back to HIPAA, HIPAA said that the Secretary in coordination with the Secretary of Commerce shall adopt standards specifying procedures for the electronic transaction and authentication for signatures, with respect to the transactions referred to in Subsection A1.

I will stop there and open it up for questions. I raised a lot of issues. I don’t have the answers. I understand you brought a lot of people to testify in the next couple of days that are going to bring you the answers. I just want you to make sure that the issues are on the table, and that you understand the technology for when they bring you wonderful stories about standard digital signatures are and how standard digital certificates are, and how there should be a PKI deployed, and all the benefits that are going to ensue from that, that you understand the rest of the picture.

So with that, I thank you for the opportunity and I am open for questions.

DR. COHN: Well, Kepa, first of all, thank you very much for a fascinating presentation. You have brought some things I didn’t know, so thank you.

I am also reminded, and those of you who have a history on the subcommittee will remember that we went into this area before. I am reminded by your presentation why we at that point didn’t make much traction.

Having said that though, I think one of the things that we will hear over the next couple of days is both some real-world experiences, but also I think we are going to be revisiting the business case. I think what we saw last time was that there was not a business case that was strong enough to get many of these issues resolved. I think what we are looking for at this point is some sort of a combination of increased sophistication of an electronic transaction, but also e-prescribing. Maybe there is enough interest for the industry to move in this area. So thank you for reminding us of all the issues that we need to deal with.

Mike, you have a question?

DR. FITZMAURICE: Kepa, a truly outstanding presentation. It is amazing. I didn’t know half of what you told me. Simon is far above me on knowing this, and that is truly amazing.

I have a simple question. That is, how are the key pairs calculated, and then how many can be made? There is a public key and a private key. How do you make those two keys? Does it take prime numbers, for example? How do you do it?

DR. ZUBELDIA: Very good, you have been reading on this. The keys are generated by either multiplying two very large prime numbers or by in the elliptic curve algorithm multiplying the two coordinates that would fit along an elliptic curve, which essentially make those keys in the prime number case very strong, because the mathematics of factoring large primes involve very expensive, very computationally intensive mathematics.

It is widely perceived and widely calculated that in order to factor a key and get the primes that compose that number, it would take longer than the age of the universe with today’s computer technology. That doesn’t include the computer technology available to a certain branch of the government. But there is this myth that the National Security Agency can break the keys. I have heard from the National Security Agency, they can’t do it, either.

Because there are so many large prime numbers, and there are so many different possibilities of multiplying prime numbers, and the prime numbers are generated with a random number generator, the likelihood of finding coalitions where by chance two people or two machines or two entities generate the same pair of prime numbers that multiply and give the same key payor, the likelihood of that happening is so low that it is considered impossible.

So the mathematics of generating the keys, because they use large prime numbers, guarantee that there is practically an unlimited supply of e-payors without coalitions.

DR. COHN: Michael, thank you for the simple question.

DR. FITZMAURICE: I didn’t say the answer was going to be simple. That is why i had to ask Kepa.

DR. COHN: Jeff.

MR. BLAIR: Kepa, fantastic overview. A lot of things that had been eluding me for a long time in the whole area of electronic signatures and digital signatures are clarified. I was wondering if it was ever going to happen, because I have tried a number of times to try to understand PKI. So for the first time, you made a lot of these issues clear.

As a matter of fact, I hope it is recorded, because I don’t think I have ever heard an overview of this topic which I was able to understand. It would be nice if it was recorded or could be transcribed to be made available generally.

Kepa, you pointed out that there is a lot of different ways that technological solutions for E-signatures that are out there, that the industry has not been able to come together on certification. It sounds as if there is maybe a little bit of convergence that we see, or at least some consensus that might be growing if we look at these things in pieces like we look at e-prescribing separately from e-mail separately from other health care documentation standards or HIPAA requirements. But that seems to be — that gets to my question.

Pragmatically, we could easily come up with technical solutions and solutions that would apply to a particular market segment. But it sounds as if, if we do that, then we are going to leave the physician in a situation where they have got to go through multiple standards because they don’t just operate in one market segment.

Do you have any suggestions for us as to how we could try to build a consensus over the different health care applications and acrose the different technologies?

DR. ZUBELDIA: Excellent question, Jeff. First, thank you for your comments on the presentation. The presentation has been recorded and I’m sure will be transcribed. You also have access to the Power Point. It is available electronically, too.

On the multiple standards — and I want to tie back to Dr. Cohn’s business case, I think that the concept of having one standard of digital signature for everything could be problematic, because there are different business cases for the different signatures.

For instance, let me go back to the HIPAA statute, where it says that the signature would satisfy requirements for written signatures with respect to the transactions referred to in Subsection A1. Well, there are no requirements for signatures with the HIPAA transactions today, but when we get to transactions such as attachments, if there is a requirement for a signature of consent, that is going to be the patient signature. The business case for the patient’s signature is going to be very different from the business case for a physician signature, where the patient may or may not have a digital certificate, most likely will not have a digital certificate.

If we look at some of the transactions today that in the paper world require signatures, such as prescriptions, in most states they have built a business case for pharmacy prescriptions that does not require digital signatures or even signature dynamics signatures. All it requires is a secret PIN. In fact, the IRS also allows you to send some of the tax returns with a PIN that they give you. They send it to you by mail and say, this is your PIN that you are going to use for your tax returns. It is a four-digit PIN.

So the business case, when it says signature, the signature could in fact be a PIN number or perhaps a little bit longer than four digits, could be a number, and that could be considered the signature. First, what is a signature? I have shown you a signature analyzer that is a piece of hardware. I have shown you a voice signature and signature captures by UPS.

So since there is not a unique definition of a signature, perhaps there is not a single standard of signatures, and perhaps those business cases need to be considered independent of each other. Perhaps there needs to be more than one standard for digital signature. A standard that will be applicable to HL-7 version three used in XML tags will probably be different from the standard used to send an e-mail attachment to sign an e-mail attachment, that needs to be detached by somebody via e-mail.

In one case, in HL-7, the signature is inside the document. In the case of e-mail, the signature is outside the document. The business case is very clear for both of them. So to try to converge that into one standard for everybody may be very difficult. Perhaps looking at the different business cases you could arrive to a conclusion that says for pharmacy prescriptions, you can use a PIN number or a secret number that the physician has, and for scale two prescriptions or scale four prescriptions, you have to use a digital signature issued by the DEA, and for electronic medical record, you have to use a HL-7 signature, and for the HIPAA transactions you use an X12 signature.

Now, I am going the other extreme now, going all these possible standards. But perhaps the business case needs to be addressing each one of them at a time.

DR. COHN: I have one question, and then we probably need to wrap up here and give everybody a break so we can go on to the next session.

First of all, I don’t want to go further down the path of a different digital signature for every purpose. That doesn’t sound exactly like something that is going to make life easy for anyone. But I am reminded that at the end of the day when we talk about electronic signature and authentication, we are talking about identity, and in some ways we are talking about identifiers, and the strength of the identifiers, the uniqueness of the identifiers. I just can’t help but think of all the other HIPAA identifiers that we have been talking about, and I’m wondering if you have any thoughts about how they all are going to intersect or interact. Do you think that some point they are either all going to map together, or one is going to at some point in the future supersede others? Thoughts?

DR. ZUBELDIA: Excellent, yes, I’m glad you talked about that. There is two different aspects to that question. The first one is, can we use the same authentication process to authenticate an individual that is applying for an MPI, and authenticate that individual to issue a digital certificate to that same individual using the same process. It would be a tremendous potential for savings for the entire industry if as part, or perhaps in parallel with the MPI application, the same process could be used to issue a digital certificate, using the same process to authenticate an individual.

So I think there is a great potential of intersection there. There is another potential of intersection, and that is the MPS, where there will be a repository of identifiers for all of the physicians in the country, that perhaps could be extended to use one of the fields in the repository to distribute the digital certificate for that individual. Perhaps the digital certificate has been issued by a third party certification authority or by CMS or by the DEA or by whomever, but it would be one place where you can obtain the digital certificates for all of the providers in the country, all of the payors in the country, and if there is ever an individual identifier, all the individuals in the country. So there are those two clear intersection points.

DR. COHN: I think with that, Kepa, we want to thank you. It has been a wonderful introduction. I hope you will be able to join us for the remainder of the day.

We are running a couple of minutes late here, but why don’t we take a 15-minute break, and then we will come back together.

(Brief recess.)

DR. COHN: Would everyone please be seated, we are going to get started. This is our second session of the morning. We have been talking about state and other issues during the session. I want to thank our testifiers for joining us, Eleni, and I still can’t say your last name, so I apologize. Then we will be having Mary Ryan and then Jeff Brown. I want to thank you for joining us.

DR. CATIZONE: I think all I can really say after that presentation is ditto, and move on to the next presenter.

We appreciate the opportunity to meet with the subcommittee and share information from the states’ perspective. The balance of what we have to offer is in our written testimony, which Eleni will highlight and summarize for you. We simply want to say, we want to work with the subcommittee to incorporate any federal requirements or standards into existing state standards, so there is a complementary and synergistic relationship. Anything that we have done in terms of defining electronic signature, defining electronic prescribing at the state level, we have presented to the subcommittee, and would like to work with you as you work toward defining those other standards and definitions.

So I will turn it over to Eleni now to highlight.

MS. ANAGNOSTIADIS: Thanks once again for giving us this opportunity. When Maria asked us to testify on electronic signatures about a month ago, I said, I hope that we can offer some information to you today that we haven’t previously. So if there are a few points that I cover that we have previously discussed in our testimony in July, I do apologize.

However, I do want to set the stage and bring back to your attention an NABP task force that was convened in 2001. It specifically started the electronic transaction of prescriptions. At that time, the task force recognized that approximately 44 states allowed for the electronic transmission of prescriptions, either through explicit statutory and regulatory language defining and allowing its use, or by default in omission of having any regulations in this particular area.

Today, I am pleased to say that all 50 states allow for electronic transmission of prescriptions in some form. Today, as i mentioned, we will specifically focus on electronic signatures; that is what we were asked to present here today.

I am going to give you a little overview of the state regulations, talk a little bit about a verified Internet pharmacy program that we have in place, and share some criteria with you, and then make a couple of comments regarding the Drug Enforcement Agency proposed rules that will be forthcoming.

MR. BLAIR: Could I just ask for one clarification before you continue forward? Because it makes a major difference in how we interpret the things you are about to tell us. When you say that almost all the states have provided for electronic transmission of prescribing in some form, does that mean by fax predominantly, because electronic signatures for fax might be very different than for the ones we are trying to grapple with, with respect to from computer to computer.

MS. ANAGNOSTIADIS: It is actually both. All the states, if I am not mistaken, do allow for fax transaction of prescriptions, but today for the purposes of this testimony, we are focusing on electronic transmission from the prescriber’s computer to the pharmacy.

MR. BLAIR: Computer?

MS. ANAGNOSTIADIS: Computer.

DR. CATIZONE: And you are exactly correct. It started out as a fax regulation or standard, with the idea of looking forward, what will be down the pike, will it be computer to computer, will there be other systems. Some of the states have regulations that were developed specifically for fax transmission, but have been interpreted broadly to allow electronic transmission. But you may run into a state or two that has some specific nuances in the regulations or standards that prohibit electronic transmission or specific activity within electronic transmission systems, but to say that that state would prohibit it blanketly probably would not be a true statement.

MS. ANAGNOSTIADIS: NABP’s primary concern regarding electronic prescribing is to insure the authenticity, legitimacy and integrity of the electronically transmitted prescription. That is really the major point that we want to drive home here today.

All of you should have received a copy of the model act in July. In our model act, we suggest that either electronic or digital signatures can be used to process electronic prescriptions, as long as the technology that is used allows for a secure transmission. So again, our biggest point here is that the prescription integrity remains intact as it moves from the prescriber’s computer to the pharmacy computer.

Electronic signature definitions and electronic signature and digital signature, I won’t read those again. We adopted those from the FDA, based upon a recommendation from our task force in 2001. It is also the same definition that Dr. Kepa spoke of earlier in the electronic signature that he referred to.

I’m not sure if you have handouts, but if you take a look at Attachment A, I want to talk a little bit about the overview of state regulations regarding electronic and/or digital signatures. I’m not going to read through those, just give you a brief overview.

Nearly half of the states require some form of electronic signature and/or other secure method of validation. A couple of the states, I believe it is Wyoming or Nebraska, require digital signatures. One thing that I would like to point out is, the state of North Carolina had a digital signature requirement in their regulations, but have recently updated those regulations to allow for electronic signatures. I thought that was an interesting point, that they have reverted from digital signatures back to electronic signatures.

Roughly one-third of the states do not specifically address this issue, and after having communication with people in some of those states, a lot of them are waiting to see what the DEA is going to come out with in order for their state regulations to be consistent with the DEA.

Many state regulations also include that the electronic order must identify the transmitter’s phone number for verbal confirmation, the time and date of the transmission, and the identity of the pharmacy intended to receive the transmission, just so they can be sure that they were the pharmacy intended to receive that particular prescription.

As I mentioned earlier, insuring the integrity of the prescription order is of utmost importance to us at NABP.

I want to talk a little bit about a program that we instituted in 1999. It is called the verified Internet pharmacy practice sites program. This program identifies and verifies legal and legitimately operating Internet pharmacies. The electronic transmission of prescriptions by Internet pharmacies is an area specifically identified in the VIPPS criteria.

Attachment B is a list of all the various criteria. There are two areas that I would like to bring to your attention, one having to do with prescription information, and the other one patient information.

One of the criteria that we look at when we go in and inspect these pharmacies that want to become VIPPS accredited is to see whether or not they have policies and procedures that insure the integrity, legitimacy and authenticity of the prescription drug order. I think those same criteria can be used here with electronic transmission of prescriptions.

We also look to see that the drug orders that are submitted and filled are being filled at multiple pharmacies, and also, we want to be sure that an in-person physical examination has taken place, and that patients aren’t just doing online consultations with physicians, and then physicians sending a prescription to a pharmacy, and that prescription being mailed to the patient.

Another part of the criteria where there may be a little bit of a correlation between electronic transmission of prescriptions and the Internet sites has to do with patient information. We make sure that the pharmacy has polices and procedures in place to verify the identity of the patient and the prescriber. We also have language in there to look for polices and procedures to insure patient confidentiality is not compromised as the prescription as being transmitted, or any information is being transmitted, whether it is from the physician to the pharmacy or back, that the integrity of the patient specific information remains intact.

I don’t know if CArmen has any more comments on this, but I’ll be happy to address any questions at the end.

I just want to make a couple of comments regarding the DEA regulations for controlled substances. it is important to note that although state regulations regarding electronic and digital signatures include controlled substance prescriptions, that the DEA is the overriding authority for what the final say is, whether they require electronic or digital signatures.

States have been working cooperatively with the DEA to achieve a productive result, to be sure that they are intertwined, but as I mentioned earlier, some of the states that don’t have language want to make sure that they are consistent with what the DEA comes out with. To date, the DEA has not published their regulations. I think they are supposed to be forthcoming, and as NCVHS is well aware, we would hope that the subcommittee would take a look at this proposed regulation, take into account what the states are currently doing prior to making your recommendations to the Secretary of Health and Human Services.

NAPD feels that the electronic signature requirements for controlled and non-controlled substances should be consistent in order to minimize fragmentation of potential barriers to electronic prescribing. So we are anxious to see what those proposed rules have to say when they come out, hopefully shortly.

In closing, NAPD recognizes the benefits of electronic transmission of prescriptions, and we understand the positive impact this technology has on patient safety and the facilitation of the processing of prescription orders. We can’t underscore the importance of patient safety. As you come up with whatever recommendations you have forthcoming to the Secretary, that you always keep patient safety at the forefront.

So with that being sid, that concludes our presentation here today, and we are happy to address any questions after the other panelists finish.

DR. COHN: Thank you. Mary Ryan, I think you are on next.

DR. RYAN: Thank you. We wanted to use this opportunity since we are talking about state issues to discuss again the issue of federal pre-emption. I will talk a little bit about state variances and how they affect electronic prescribing to the negative, if you will, and then we will turn it over to Geff Brown, who will talk about the legal issues associated with pre-emption in the MMA.

When you have variances at the state level, that is exactly what you have. Unless we have a national standard for all aspects of e-prescribing, whether it be the electronic signature standard or other components of electronic prescribing, prescribers and pharmacies will encounter barriers to implementing the technology in order to meet the expectations of each state.

Model rules serve a very important purpose, but they don’t actually result it a national standard. Model rules are exactly that. They are templates that states use to then personalize the modify the rules based on state initiatives. It is important at times to have state variances, because when you have state variances, oftentimes a very innovative and proactive state will introduce innovation into the practice. But when you are looking at segments of the population having a particular standard applied to them, in this case, the Medicare segment versus the rest of the general public, then you result in discontinuity, and we need a national standard and not simply a model rule.

Medicine including pharmacy is practiced these days acrose state lines. Approximately 18 percent of prescriptions are filled in mail order pharmacies and sent across the United States, and there is a growing segment of the population using what are referred to as specialty pharmacies. These are pharmacies that specialize in home infusion and other home care types of prescriptions for people who have significant disease states that require special attention and special medications. These are typically not located in the same state where the patient resides.

In general, if you look at the way that prescriptions are filled across state lines or in pharmacies, if the prescriber state does not allow an electronic prescription, then the pharmacy can’t accept an electronic prescription. Likewise, if the pharmacy state does not allow an electronic prescription, even though the prescriber state may, that pharmacy can’t fill an electronic prescription. I think that in general, prescribers have an expectation that when they write a legal prescription, it is going to be honored in any state that it is sent to.

At the state level — Eleni touched on this a little bit, I wish to elaborate a little on that. I used the NABP survey of pharmacy law to come up with these numbers. That is a static survey and there are probably some changes to these numbers, but in that survey, I found that six states actually don’t allow e-prescribing, and eight states have what Eleni referred to as the not prohibited clause. That means that they haven’t adopted any rules or regulations, but they also aren’t actively prohibiting an electronic prescribing system from functioning in the state.

At the state level, there are 36 states that have adopted regulations, but there can be some significant state variances in these regulations. From that NABP chart, there were 12 footnotes associated with the regulations that the state has adopted. In two of the states, the electronic prescribing systems and vendors have to go through a board approval. I also believe that in many cases, electronic prescribing systems will seek board approval when there are no supporting rules and regs, because they just want to make sure that it is a legal activity.

One state has a no direct lines to the pharmacy. In other words, it is intended to prohibit electronic prescribing from going only to one pharmacy and to protect the patient’s choice of pharmacy, but you do sometimes have systems that will require a direct line, if you have for example a closed hospital system that wants to do a direct access to its pharmacy, that would be an example that would be somewhat in violation to this concept.

Most of the states or many of the states have a provision that I will just refer to as no access to the prescription in the transmission process. Again, this is intended to extract a good intention. It is intended to prevent unauthorized exchanges to the prescription after the prescribing has locked the prescription in place. But in order to transmit the prescription to the patient’s choice of pharmacy, you have to open up that transaction to see where to send it, so you have to at least look at the routing detail to send it. So some vendors have been concerned that this kind of language prohibits them from even beginning the electronic transaction.

Continuing that, individual states have adopted the concept of no controlled substances or no schedule two substances in an electronic prescription. I think that many of these states are waiting for DEA regs related to controlled substances, but those regulations stay in place after the DEA has adopted rules unless the state changes their regulation. This causes a disconnect between federal and state law, and when you are talking about controlled substances in particular, the stricter law applies. So even if the DEA does pass these rules, the state then has to go back and change it, and sometimes they don’t. Sometimes they really don’t want controlled substances to be subject to these sorts of methodologies.

In one state, we have an issue where the prescriber may only be licensed in the state where the pharmacy is in order to accept the e-prescription. So in that state, even if the patient goes acrose the border to a specialty clinic, for example, that prescriber could not send that electronic prescription into that state for that pharmacy to dispense that prescription. Many states require that paper records be maintained once the e-prescription is maintained. So even though you have this well authenticated and secure system, the pharmacy is then required to produce a piece of paper which we all know is subject to misfiling and mishandling along the way.

There are many times when, because of all these barriers, oftentimes what results is that you don’t actually get a true electronic prescription. You do in fact get a facsimile prescription or a hard copy prescription which is generated from the electronic system. You have this medical system at the doctor’s office capable of sending an electronic prescription, but because of these conflicting laws, the prescriber chooses to reduce that to paper or to fax in some way. Oftentimes this will happen at the patient’s behest as well. They are not ready to pick a pharmacy, they are not ready to get the prescription filled, so they ask for a paper prescription, so I don’t want to suggest that it is all related to the discontinuity of laws.

For these, 33 states allow on faxes what I will refer to as an electronic signature. Here it is the signature that Kepa showed you in the facsimile prescription, where you have a signature that looks like the doctor’s handwriting, or it may be a printed name that is created out of the electronic prescribing system, which has been validated, but it really doesn’t look like a signature per se.

And 28 other states require — and that adds up to more than 50, and that is because we have Puerto Rico and the District of Columbia and so on — those other states allow hard copy prescriptions to have an electronic signature, and the remaining states require that the prescriber physically sign those prescriptions. So even though you created this electronic prescription with a valid signature or a valid representation of your signature, if you hand that piece of paper to the patient you have to take it back and physically sign it before they leave the office, because it then falls under the written prescription rules of that state.

So unless we have a national standard for all aspects of e-prescribing, prescribers and pharmacies will encounter barriers to implementing the technology needed to meet the expectations of each and all states.

Again, we do ask that you consider the concept of federal pre-emption for electronic prescribing, including the electronic signature component. With that, I will turn it over to Geff Brown to make a legal case.

MR. BROWN: I am Geff Brown. I am an attorney with Mayer, Brown, Rowe and Maw. Thank you for inviting me to come over and testify. I have worked with a number of folks who are going to be testifying here today, but I personally am testifying on my own behalf. I am not an attorney for any of the clients.

I’d like to interject — there was a question after Kepa’s very good presentation about the number of primes and whether there were enough for everybody. There is a prime number theorem which says that at the number N, the probability that that number is prime is approximately one over the log of N, which means that if you take the number of bits in a binary number or digits in a decimal number and you take a reciprocal of that, that is the chance that you are going to have a prime number.

When you are talking about these large numbers, that means that there is a huge number of primes at that size. It is fairly likely that you won’t have any overlap unless two people are using the same algorithms to generate primes. So that is how that works. The reason that primes are important is that the public key is essentially two primes multiplied together, and the private key is essentially a prime number, and you need to have a way to generate a private key using a prime number generator. We all hope that it is not easy to figure out the two primes that are multiplied together, otherwise lots of things fall apart.

But back to what I am here to speak about, I wanted to identify some of the state legal issues that restrict electronic prescribing. I also wanted to discuss the pre-emption provision in the MMA, which we had some discussion about in the subcommittee hearings in the Privacy and Confidentiality Subcommittee. Then lastly, I wanted to talk a little bit about the electronic signatures in the Global and National Commerce Act, which Kepa also referred to, known as E-sign, and how that affects your looking at the digital signature/electronic signature issue.

First, state legal requirement, which Mary actually did a very comprehensive job on. But from my point of view, tracking electronic prescribing laws and regulations at the state level is very time consuming. A few states as Mary pointed out have laws and regulations that make electronic prescribing impossible, and many more have laws and regulations that place significant barriers on electronic prescribing. These barriers include outright prohibitions, requirements that a state board approve systems, prohibition on transmission of prescriptions to or through an intermediary, requirements for patient consent to electronic transmission, or if you don’t have consent, having to print out a copy and go through the written prescription procedures, restrictions on pharmacies accepting scripts written by out of state prescribing by physicians, requirements that pharmacies verify scripts, and this is a requirement generally with respect to prescriptions, but there is no guidance for pharmacists in many states on how to do that verification on electronic prescription. There are confidentiality restrictions on the transfer to prescription information, such as medication history. Then finally on my list, there are format and content requirements on scripts such as having a second line for a signature to avoid generic substitution, which has to be considered when you are doing an electronic signature prescription program.

This list hints at the variation among states. I should note that even though there is some schizophrenia among states, such as through the model act that Eleni spoke to, not all states adopt it, and some states adopt variations at the legislative level, and other states, even if they adopt the same language, end up having slightly different or very different state board interpretations of the language.

The issue of the variation among the states in laws and regulations is a barrier to entry for developers of electronic prescribing systems. Developers who want to create a nationwide system must spend money and develop resources to survey the laws and regulations, keeping those surveys up to date, and even once they have a surgery, they need to understand how the state board will interpret the regulatory or legal requirements, so they have to contact the individual boards to understand that in most cases. This is particularly an issue because most electronic prescribing laws — in fact, I can’t think of one that isn’t in this situation — haven’t been tested in the courts. So the state board of pharmacy interpretation is the interpretation on which we have to rely when we are advising a developer.

Even once the developer has collected all the written laws and regulations, the developer will likely find that there are a number of states that will not permit its system, and this leads to another cost, which is trying to change or to implement regulations in those states that don’t permit electronic prescribing.

One way that developers have tried to avoid this cost is to limit their focus to only a single state or to a number of closely related states. This has happened in a number of instances that I know of. The problem is that this could lead to fragmentation in the market, where for instance the system in one state on the East Coast would be different than the system in the West Coast. Then you have to do the back end work of integrating those two.

Then even more than developers of electronic prescribing systems, physicians and pharmacist lack the time and resources and the expertise to determine whether a particular electronic system or use of electronic prescribing is legal. I could say that I would like them to call me up and ask me the question, but realistically what they do is, they are chary of using electronic prescribing if they are concerned that the rules are complicated, and in particular because getting the answer wrong can expose them to professional liability, so that obviously decreases the demand for electronic prescribing.

Congress understood the problem. They created an exemption provision in MMA, and I have the site reference here. I will read the language, which is, “The standards promulgated under this subsection shall supersede any state law or regulation that A, is contrary to the standards or restricts the ability to carry out this part and B, pertains to the electronic transmission of medication history and of information, eligibility, benefits and prescriptions with respect to covered Part D drugs in this part.”

This section insures that standards adopted by the Secretary will pre-empt state laws and regulations that could otherwise defeat the purpose of MMA’s electronic prescribing program. The provision makes explicit the power under the Constitution of the MMA as federal law to supersede and pre-empt laws and regulations. In doing so, this section refers expressly to the standards that the Secretary will promulgate with the advice of HHS.

In previous hearings both of the Subcommittee on Privacy and Confidentiality and of this subcommittee, we have discussed the warning and particularly the use of the word “and” between subsections A and B of the pre-emption provision. We have noted that this is a provision that the legal staff at HHS will need to interpret for the final regulation.

Although the legal effect of the section is generally an issue for HHS in the regulatory drafting stage and not for NCVHS at this stage, I do believe NCVHS has a role to discuss the policy case for pre-emption of state laws. That is because the scope of pre-emption is not only a question of interpreting the words in the statute, but also a question of implementing the intent of the statute. I would note that not only the intent of this statutory provision, but also pre-emption as implied pre-emption as a general matter when you are talking about federal statute. I believe that NCVHS can and should give guidance to HHS on the practical need for single nationwide standards and the efficacy of various ways to achieve MMA’s goals.

I believe that a nationwide set of electronic prescribing standards all physicians and pharmacists can use in all states for all patients will reduce complexity and legal risk, but that adding yet another set of rules only for Part D will add to complexity, and added complexity could lead to the decrease of adoption of electronic prescribing overall. Physicians and pharmacists may not have the patience to use different electronic prescribing programs based on whether their patients are covered by Part D or not. Given the significant potential benefits of electronic prescribing which have been well noted by this subcommittee and in the literature, NCVHS and HHS should interpret the interpret the pre-emptive force of MMA in a way that promotes nationwide standards, rather than in a way that might lead to added complexity and to physicians and pharmacists being less willing to adopt electronic prescribing.

Some words on electronic signatures and E-sign, which is another pre-emption issue. The E-sign act which Kepa referred to, and which was passed and signed by President Clinton in June 2002, is a short statute, and its key is in the Section 101-A1. Notwithstanding any statute, regulation under rule of law, other than titles in E-sign, with respect to any transaction in or affecting interstate or foreign commerce, a signature, contract or other record relating to any such transaction may not be denied legal effect, validity or enforceability solely because it is in electronic form.

This provision likely applies to electronic transfer of prescriptions, and they also apply to other transfers of prescription related information. Although the scope of E-sign is limited by the definition of transaction, that term is defined broadly by E-sign as an action or set of actions relating to the conduct of business, consumer or commercial affairs between two or more persons. I believe prescription is covered by that. We have a case in the Supreme Court about the scope of the commerce clause, but assuming that the prescription affects interstate commerce, I think E-sign will cover the electronic prescription programs.

E-sign not only makes electronic transactions enforceable, but it also pre-empts any statute, regulation or other rule of law that attempts to impose the implementation or application of a specific technology or technical specification for performing the functions of creating, storing, generating, receiving, communicating or authenticating electronic records or electronic signatures. The E-sign defines the electronic signature in a technologically neutral manner was an electronic sound, symbol or process attached to or logically associated with a contract or other record executed or adopted by a person with the intent to sign the record. Consequently, mandatory adoption of digital signatures as a statutory or regulatory preferred means of electronic signatures, including electronic prescriptions, is no longer possible at the state level.

Not only does E-sign pre-empt specific state electronic signature rules, but it also constrains federal rulemaking authority. E-sign’s Section 104-HQ-C3 contains a provision restricting both federal and state regulatory agencies from issuing guidance for use of electronic signatures that is not technologically neutral. However, there is an exception in E-sign Section 104-A3A, for regulations that specify performance standards to insure accuracy, record integrity and accessibility of records that are required to be retained. This exception permits regulatory agencies to impose functional requirements on systems that meet regulatory goals without compromising the technological neutrality of E-sign.

As you develop recommendations for electronic prescribing, I ask that you bear in mind the restrictions that E-sign places on both state and federal regulations related to electronic signatures. However, since E-sign does not prohibit NCVHS from including standards for accuracy, integrity and accessibility of electronic prescribing records, you may want to focus on how current technologies, whether or not specific to electronic signatures, achieve those goals. Then based on your findings, NCVHS can set requirements for electronic prescribing based on how best to achieve those goals.

In conclusion, NCVHS has an opportunity in preparing its recommendations to the Secretary to create standards that through pre-emption can reduce barriers to entry into the electronic prescribing market, can offer users, both prescribing physicians and pharmacists, a single set of functionality that is simple to use in the multiple standards currently mandated by state rules. Pre-emptive MMA standards can promote rapid adoption of electronic prescribing, which offers the potential to save lives, reduce costs and improve privacy and confidentiality.

Thank you again for the opportunity to testify to you today.

MR. BLAIR: I think there are two major points of guidance to the subcommittee. One was that we do wind up indicating that the federal laws or regulations for E-signatures, for e-prescribing, apply to all states. It seems like you want to make sure that states will not have the freedom to pre-empt or override the federal laws. I think I heard that message.

But the other piece, Geff, that you just told me, I just want to make sure I understand this correctly, because it sounds like what you are saying is that the E-signature law from two years ago really gives us very broad latitude in terms of what we recommend. If I heard you correctly, you were saying that even though the law should be technology neutral, if we were to identify that for accuracy, integrity or accessibility, I think were the three criteria that you articulated, that if a particular function or technology were desirable, we even have the latitude to make recommendations for a particular technology or functionality that might not be fully technologically neutral. Did I hear you correctly?

MR. BROWN: The language of the statute says, be technologically neutral, but with respect to records retention, you can put functional requirements that don’t define the technology that meets those requirements. That says essentially if the technology doesn’t meet the requirements, then it is not acceptable for the purpose.

MR. BLAIR: That was records retention, so maybe that is not with respect to — in any event, I think your message was that we have broad latitude, is that correct?

MR. BROWN: I don’t want to say that it is broad latitude. I want to say that you have latitude within the confines of what E-sign permits. I would also point out that the OMB has issued guidance, and a number of other agencies have issued guidance internally, so you can go out and look to see how other regulatory bodies have dealt with this point.

The purpose of E-sign is to allow electronic signatures without regard to technology. It was particular because at the time — as you know, Utah was the first state to do it, but there were a number of states that were putting together their own home-grown digital signature acts, and there was a concern that they were going to be different among states The problem that was perceived in the Utah statute was that it was prescribing very detailed rules on, here is the way that you have to do digital signature if you want to get the full legal effect of Utah’s statute. E-sign essentially swept that away and said, we understand. In certain circumstances, it is important that things be more secure than just some of the weaker methods that Kepa pointed out.

MR. BLAIR: Maybe if you can just restate that one phrase that I thought was giving us even broader latitude. I think the phrase included accuracy, integrity and accessibility. Could you restate that, and clarify exactly what freedoms does that give us.

MR. BROWN: I’ll read it from Section 104-A3A, which is, a federal regulatory agency or state regulatory agency may interpret Section 101D to specify performance standards to insure accuracy, record integrity and accessibility of records that are required to be retained. Such performance standards may be specific in a manner that imposes a requirement in violation of the technology neutrality section, if the requirement, one, serves an important governmental objective and two, is substantially related to the achievement of that objective.

I should say, nothing in this paragraph shall be construed to grant any federal regulatory agency or state regulatory agency authority to require use of a particular type of hardware or software in order to comply with Section 101D.

DR. COHN: I think Carmen had a comment also.

DR. CATIZONE: I’d like to go back to Mr. Blair’s first comment about federal pre-emption and maybe just put that a bit in perspective, rather than to respond to any of the previous comments.

We are moving away from any requirements for federal pre-emption. We want the states to define the logarithms for the prime numbers. We think that is probably where the real — I’m just kidding. When we look at federal pre-emption, NABP and the states are not opposed to federal pre-emption, but you have to make sure certain things occur with pre-emption. You have to look at why the states have certain requirements in place.

There were no federal standards, so the states have responded to situations they found. If the states require that a physician could not e-prescribe in a state because there were no standards for validating the authenticity or integrity of that physician, if a requirement prohibiting e-prescribing or electronic transmission, it is because we have documented cases, and by documented, we mean indictments, pharmacies that have been involved in fraud, abuse and kickbacks involving prescribing.

So if you go with a very broad federal pre-emption that eliminates all the states’ safeguards, what we would ask in return is that you put in place very stringent federal safeguards that mimic the states, so that we don’t have the indictments for the kickbacks and other abuses that the states have uncovered.

Again, as Eleni mentioned earlier, a lot of this has to be coordinated with the federal agencies. Paper requirements go back to the Food Drug and Cosmetic Act. The language is still there, and it is still interpreted by many within the FDA that a prescription must be immediately reduced in writing. So again, the states are mimicking federal actions and the lack of any federal standard in how they are addressing problems at the state level.

Even though it may be a slow process, the states will work to change regulations that come into conformance with federal requirements and federal standards. All I am asking is, don’t remove everything and allow people to act without any safeguards or without any rules.

MR. BLAIR: Thank you.

DR. COHN: I want to ask Geff a question also. I want to thank you, Carmen, for the clarification as well, and I am hoping we are going to be able to put to rest the prime number discussion sometime this afternoon. And Michael, thank you very much for that question earlier today. I had no idea there were so many mathematicians in the crowd.

I need to go back and review the E-sign legislation. Maybe I am misreading the areas that you quoted, but when Geff talked about wide authority of the agencies or the federal government, I am wondering if this is actually very narrow authority. Maybe you can clarify. I see electronic signature being mentioned with additional requirements that an agency can impose for retaining records and things like this, but I am not hearing wide discretion around the use of digital signatures.

Obviously you are a lawyer, and you are one of many lawyers in the room. I am not looking at the actual legislation, but what was your intent of quoting these specific passages, and am I misreading what your intent was from your comments?

MR. BROWN: I should have been more clear in my intent int the presentation. I don’t believe you have wide discretion, but I wanted you to understand there were specific statements in E-sign that say you as a federal regulatory body can’t do certain things, but there are exceptions, that you can do things.

Now, interpreting that, I’m sure the HHS lawyers are going to be looking at this very carefully, but if I were taking a look at it, I would say, you have the right to say that whatever security system or authentication system is used for electronic prescriptions, whether that be a digital signature, an electronic signature, some other type of process, auditing, whatever it is, it has to meet a level of verifiable tracking of authentication, so that you don’t have various prescriptions in the system.

What I don’t think it lets you do is say, thou shalt use digital signatures using keys of at least 256 — you know where I am going with that. The technology has to be open to anyone who can implement a system that meets the functional requirements. So it is the difference between setting the procedure to get to the goal and setting the goal. You can set the goal and that can inform how people end up implementing the system.

DR. COHN: Let me just ask one final question just to follow this up. It may be my continued confusion in the world of E-signature versus digital signature, which are sort of the same, but have slightly different definitions.

There is the concept of security and a secure transmission, but then there is also the discussion about digital signature versus electronic signature. I think what I am hearing you say is, your position would be that you don’t feel that the government can say that there needs to be a digital signature.

MR. BROWN: That is correct.

DR. COHN: I just wanted to make sure I was understanding precisely what your comment was.

MR. BROWN: Here is the problem that I see. The case law on E-sign, which I looked at a couple of months ago, up until a couple of months ago, all the cases were essentially, if you send an e-mail, does the fact that you typed your name at the bottom constituted a signature. The answer is, if you intended it to be authenticating a record, yes. So people are forming contracts by sending e-mails now, which I think what the Congress wanted in 2000.

I don’t believe that NCVHS will be recommending that as long as the prescribing physician types his or her name in a field, that that constitutes enough or validating that that is the prescribing physician who sent the prescription, because anybody can type that in. It would be difficult as a factual matter to go back and find out whether the prescribing physician typed the name, or whether somebody else in the office, or somebody spurious did that.

I think you can accept E-sign as defining the results that you want. On the other hand, I don’t believe that the exception I read to you permits you to say you must use asymmetric PKI digital signatures.

DR. COHN: Thank you for your interpretation. I think that is important, and obviously we need to read it.

MR. BLAIR: I just wanted to clarify. I’m not sure that I understood you correctly. Are you saying that if for some reason for e-prescribing, whether it is according to the Drug Enforcement Agency or other requirements, that we would not have the latitude to indicate that the electronic signature standards for e-prescribing would be either pretty good privacy or digital signatures. Are you saying we don’t have the option of selecting a particular standard like those two examples, for example?

MR. BROWN: It is a very difficult question. I will say this. I think that you have latitude under the MMA to set standards. You could set a standard that requires physicians to use particular technologies. That is clear from the MMA.

Where that runs into E-sign is a difficult question. I think under E-sign, you don’t have latitude to say you just use ABC, a particular brand. Under your regulatory authority under MMA, you could probably put in place requirements with respect to specific technologies, and it would be in parallel with the electronic signature requirements.

So I don’t want to be on record as saying that E-sign prohibits you from requiring people to use certain technologies. I am saying that as far as how it is interpreted as a signature under law, I don’t believe that you can say that a signature under law has to be a certain type of digital signature.

MR. BLAIR: It sounds like there is a little bit of a blur in here, as if you are saying that digital signatures are a technology as opposed to a standard.

MR. BROWN: It is the difference between digital signatures being the only permitted technology to sign versus a standard that must be used in this set of standards that you are going to be recommending; as a general matter, that people need to use this as a way of maintaining —

DR. COHN: I don’t think Geff is going to completely answer our questions on this one, but we do have testimony as the day goes on from others in the federal government that we will be able to get some additional clarification.

Geff, I want to thank you for going as far as you can, but I realize that you are testifying, and obviously your opinions are your own.

MR. REYNOLDS: I appreciate your testimony, and also what we heard from Kepa this morning. As we sit here and it is not even lunchtime yet, we have a lot of considerations thrown at us.

If you think about what you said about the states and the DEA and Part D, and as we think of mail order and we think of telemedicine and we think of all the other things that are being considered right now about the location of the caregiver and/or the dispenser are not necessarily in proximity to what they used to be in our world, I am struggling with what I have heard this morning. I am struggling with the fact that I haven’t got a prescription this week, and it was electronically faxed by the physician, which meant some kind of signature showed up on it, which was secure, unsecure, important, not important. We send out 30,000 checks a day with digital signatures on them, big deal. That is the ability to capture a signature, put it into a system and have come out at the bottom of something.

What is viable versus hysterical? If you think of our current process, security doesn’t enter my mind, and the safety that that is necessarily a real doctor doesn’t enter my mind. When I got the prescription, I wasn’t even asked to show ID, I just had to sign it, and I was there.

So I find as we go from where we are, which is truly doing what we are doing, all the way to where we could do any of the things that Kepa said today, and then more importantly, as I sit here, I try to think of physician adoption and whether or not the patients are going to get what they need in a reasonable time. That individual patient adoption is going to have a lot to say. We can sit in here and do everything, but that individual patient adoption is going to decide whether or not this thing works.

So any help you or the rest of the testifiers can be, so we don’t swing this pendulum all the way from — that fax just really hit me the other day, because anybody on their PC can sit and mess around. Kepa was saying today how long it takes to duplicate; you can sit a long time at your own PC and do some things, create an electronic signature and then shoot somebody out to anywhere, and then somebody comes in, signs, and they are out of there.

So any help you can be, because that ability to move this through a good structure, but not get so hysterical that we have probably gone ten to 15 times more stringent than we are currently. Yet there are a lot of drugs under all the auspices of states and the DEA and everything that are flowing out of pharmacies.

So that would be one thing that I am struggling with right now.

DR. RYAN: I want to just make a comment about fax prescriptions, so that you don’t feel like they are totally insecure. There are ways to validate that the fax came from a doctor’s office, for example. In the power setting we have recorded all of the fax numbers of the prescribers, and we verify that the fax came from one of those numbers.

So it doesn’t just come from any old computer or any old fax machine. There are ways of validating those things. In fact, you can do that now with fax technology as well as the paper prescriptions you get. So if we can apply those practical, logical things to electronic prescribing, I think it would be helpful, and it would increase the adoption of the technology.

DR. CATIZONE: That is what you were asking too with the federal pre-emption. That whole infrastructure is in place behind the scenes, so that patient walks into that pharmacy and that pharmacist is assured of the integrity of the prescription through the processes which Mary described.

There is some relationship with the patient, or some assurance that because that prescription is legitimate, the patient must be legitimate. We don’t want to destroy that infrastructure by opening this up so wide that those safeguards are not in place. That is why we are asking to work very closely with the states to make sure those safeguards are kept.

DR. WARREN: This is early in the morning, being hit by all this. I need to ask Geff to explain something, because I’m not even sure I can ask a question yet.

I need to understand the relationship between what E-sign tells us about signatures and what the MMA tells us. Is there some — I don’t know if pre-emption is the right word, but does E-sign limit what we can do in MMA?

MR. BROWN: I need to be crisper in my response. I’m trying to toil with some of the boundaries that we have, and it is a difficult question.

First of all, E-sign pre-empts states, so a state can’t come in and say that for the purposes of anywhere in their state statutes and in the common law, the word signature appears or signature is required, that you must use a certain technology. E-sign doesn’t pre-empt what the federal government does. After all, you guys are at the same level. MMA is at the same level, in fact, it is a subsequent statute. So from that point of view, it doesn’t have to worry about E-sign stopping MMA.

The problem is that E-sign does say that in interpreting the requirements of E-sign in the context of regulatory activity under other federal statutes, federal agencies should follow the rules that I was just mentioning. I think I should be clear that my comments about what you can and can’t do as a regulatory body with respect to mandating or requiring technologies, or giving certain technologies a higher level effect, is specific to interpreting E-sign in the context of MMA, and in providing for an interpretation of the word signature with respect to MMA and with respect to state laws that would still apply to prescriptions that are sent under the MMA standards.

So I want to be clear about that. You also have under MMA a very clear statutory direction — HHS does and you specifically under HHS — to provide recommendations with respect to a broad set of standards that are beyond just defining the signature. In that context, you have a great deal of latitude.

So I don’t want to say that there is anything wrong with your taking a look at digital signatures. I just want to put it in the context of what E-sign has said and the policies there.

DR. WARREN: Then does E-sign define what a signature is? I am thinking back of what Kepa talked to us this morning, where there were lots of ways to identify who was originating it or talking about it.

MR. BROWN: That’s right. I think Kepa’s slides have, and my testimony has the exact statutory wording. But the bottom line and the way the cases refer to this is, if somebody does any kind of marking on any kind of electronic record, whether it be a sound recording, or even the fact that your e-mail header shows that it came from your account, you typed this and said, I want to order a hundred widgets, the courts because of Brett and the technological neutrality in the E-sign definition of signature, which I can read to you, it is that broad.

So that is what E-sign did. What it was trying to do was to set a low standard for signatures. At the end of the day, if there is any question about whether a mark on an electronic signature is a true electronic signature under E-sign, you have to do a little bit of factual going back and saying, was this actually put on at the time the person was trying to authenticate the record, and if so, did they intend to authenticate when they conterminously put that mark on the record. That is a lot of effort, and it is a lot easier when you are talking about records that are going to be stored for a long time, to have some way of just looking at the document without having to do a whole lot of factual investigation to determine that.

DR. WARREN: One final comment. When you told us that the law prevents us from recommending a specific technology, you are talking about something that a company does; it is a brand name or a particular approach. But we could recognize that there must be a process for validating something, and we could refer back to something that ASTM is working on, or any of the various standard organizations.

MR. BROWN: Yes. It is hard to say where the line is drawn between saying thou shalt have X, Y and Z, and you have read it from a particular company’s manual, and where you end up actually mandating a particular software technology or the signature.

Again, to get back to the point I made before, this is specifically with E-sign, not with respect to MMA. In MMA, you are recommending specific standards that have come from specific standards organizations, and that is clearly within your purview in MMA.

DR. FITZMAURICE: Another short question. After absorbing the testimony in the second panel, I’d like to know what best serves the pharmaceutical industry, to have a weak signature where you have to do investigation of intent, or to have a strong signature that may sharply limit the widespread use of these signatures. Those are my assumptions, not anybody else’s. What serves the pharmaceutical industry? Then we have to think the benefits to consumers and practitioners, representing retail pharmacies.

DR. COHN: The state boards of pharmacy and PBMs.

DR. FITZMAURICE: You’re right, I didn’t mean the pharmaceutical industry, I meant pharmacies. What best benefits pharmacies? What best protects the people that your boards are to protect? What do you recommend that we recommend to the Secretary?

DR. CATIZONE: NABP can’t speak on behalf of the pharmacies, but we certainly would like some sort of system to validate the signature, and not allow it to be a weak requirement. If the discussion on the E-sign is true, that basically means anyone can write a prescription and sign their name to it, and all the authentication procedures that are in place at the state level and to the payor processes in the government agencies are really meaningless at this point, and that is going to pre-empt all those requirements anyway.

So we are very concerned about that. We would be very concerned about a federal pre-emption that opened the door and then set that as the baseline standard. We would prefer that there be some sort of authentication or requirements for electronic signature and digital signature that separates a tremendous lot of people with disability to only those that are legally entitled to do so.

DR. RYAN: I think that you can set authentication of the system and the entire process of the e-prescribing, and within it have the validation of who the prescriber is, whether you use a digital signature or an electronic signature or other representation. If the system is validated from end to end and authenticated, then I think you have your protections in place, and that is what will give you easier adoption at the pharmacy and prescriber level.

I don’t disagree with Carmen that you have to make sure that this is a valid prescription, of course you do. But I think if you can authenticate the process and the players and therefore the transaction, you can have a secure, safe and valid prescription in the electronic prescribing arena.

DR. COHN: Stan.

DR. HUFF: This is along the same lines that other folks have been asking. Has there been enough experience to know for instance in the one or two states where they require digital signatures a difference in conviction rate or detection of fraud or other things? Do we have any idea of what we get for the value of the greater complexity and greater security of the process?

DR. CATIZONE: I would say at this point, that hasn’t been determined. I don’t think we would be able to establish that there is any difference at this point between the digital signature and the traditional validation, simply because the system itself operates effectively and has its validation processes established. The digital signature is just another validation of the process.

So at this point I can’t say that it has made a big difference. I don’t know if Mary’s or the other experiences are different. It is also not widely used, so it is difficult to get a good sample size of whether it is effective or not.

DR. COHN: I think with that, thank you very much for some very interesting testimony, all of you, obviously much food for thought. I think we are going to have to get a copy of the E-sign legislation and look through it, because my memory is not that long, which is good.

MR. BROWN: You may also want to take a look at the OMB guidance, because that is helpful.

DR. COHN: And OMB will be testifying later on today, so we will obviously be talking to them further about it.

DR. WARREN: Do we need a copy of this FDA Drug and Cosmetic Act that you were talking about, Carmen?

DR. CATIZONE: Sure, we would be glad to provide it. It is available though from the FDA website.

DR. COHN: Normally we don’t publicize the ability to send us comments after our hearings, but taking from our Privacy and Confidentiality Committee, where their chairman routinely indicates that people have two weeks after the time of their testimony to send us additional comments, we would certainly make that available to you and others who may be testifying, in case there are additional comments you want to make on any of these issues. The e-mail address is mfriedman@cms.hhs.gov.

Anyway, thank you very much. We are running about 15 minutes late. We will adjourn for an hour and come back at 1:15. Thank you very much.

(The meeting recessed for lunch at 12:13 p.m., to reconvene at 1:15 p.m.)

A F T E R N O O N S E S S I O N (1:15 p.m.)

DR. COHN: We will ask Kepa to come back up and make a couple of additional comments on e-prescribing.

DR. ZUBELDIA: Sure. During the break I talked about an example of technology dependence and technology independence, clarifying what Geff was saying late this morning.

If you have to do something that is technology independent, you probably cannot say for digital signature you have to use public key encryption technology, so you are limiting it to a specific technology. But you could say that the signature has to have certain attributes, and one of the attributes could be that the signature has to be mathematically verifiable.

In theory, that is technology independent. Any technology that satisfies that attribute will be good. In reality, signature dynamics doesn’t have the ability to have mathematical authentication 100 percent verifiable, because there is viability between signature and — if you want to express that the signature has to be maintained together with the document, or that the signature has to be capable of being separated from the document, those are attributes that you could use to narrow down the technologies that can be used.

For instance, if you say that for document integrity purposes that you have to be able to use the document and you don’t have access to the signature software, that automatically includes the possibility of having the document included in an encryption package that would include the signature and the document together. It would force the signature to have that different attribute, and perhaps there are only two or three technologies that satisfy that.

So you could narrow down your technology independent requirements to the point where you are not precluding any future technology. Perhaps today there is only one or two technologies that satisfy those requirements.

Does that make sense?

DR. COHN: I think you are suggesting descriptions as opposed to technology.

DR. ZUBELDIA: You are describing the end goal. The end goal has to do this. You don’t say how you get to the end goal, but you know that today perhaps there is only one way to get to the end goal, although there may be more than one way tomorrow. But it is not a technologically driven end goal. So there is flexibility there.

DR. COHN: Michael, did you have a question? You pass. There will be an open session, open microphone, later on today.

Jerry, first of all, thank you for coming in and joining us.

MR. BUCKLEY: My name is Jerry Buckley. I am very pleased to be with you today. I act as general counsel of the Electronic Financial Services Council, an organization of leading companies in the financial services industry. I was invited to share the experiences of the financial services industry in developing electronic signatures. I do not purport to be an expert in the e-prescription area. I will answer whatever questions you have as best I can, but I’m not an expert in that area.

I came over a little early and caught the tail end of the prior discussion, so I realize you have been deluged with legal comment. The use of the Internet presents both hazards and opportunities, and the rise of e-commerce is credited with significant advances in productivity. But parties that have been operating in e-commerce, including financial services firms, thought that it would be prudent for them to obtain electronic signatures.

Under the common law, the signature can take any form. It can be an X or you have seen the cross, and it says John Doe, his mark. Nevertheless, as businesses have moved online, there is a concern that signatures obtained through electronic means would not be valid and the electronic records would not be valid or capable of being introduced and enforced in court. So to help address these concerns, a lot of businesses have reaped the benefits of electronic commerce through two acts, the Uniform Electronic Transaction Act enacted at the state level, and the federal E-sign act, or the Electronic Signatures in Global and National Commerce Act, as Congress called it. Both of them apply to transactions in commerce. Both statutes cover consumer and commercial transactions. In addition, there is a clause that covers it to expand governmental transactions at the state level.

The laws have and continue to have a profound impact on the online environment. Even before the adoption of UETA, some states have adopted electronic signature laws. There were concerns that these laws varied among themselves, and made it very difficult to transact business online in what is essentially a borderless medium. In response, a group called the National Conference of Commissioners on Uniform State Laws established a committee to draft uniform electronic records and signature act. NCCUSL’s final draft was reported in 1999, and 47 jurisdictions have enacted the UETA so far.

There are unfortunately some variations in that statute as adopted at the state level. Due to concerns about that and about whether UETA would be rapidly adopted, in the year 2000 the Congress borrowed many concepts from UETA to pass the federal statute, the federal E-sign act. While it is largely the same as UETA, it does have some very special provisions related to the provision of information to consumers, which would otherwise have to be given in writing.

There are significant features of E-sign and UETA. Both are technology neutral statutes, and I heard that discussed before, designed to put electronic records and signatures on an equal footing with their paper counterparts. Accordingly, they both operate as overlay statues with many thousands of state and federal laws.

Neither statute changes the substance of the underlying law. For example, all of the elements of a contract such as offer, acceptance, capacity and consideration, must be present in an electronic context. UETA and E-sign also do not change the standards for the validation of a signature, except to allow the signature to be in electronic form. Moreover, standard and UETA do not change disclosure requirements, other than to allow for electronic delivery.

If for example a law requires that a disclosure be made at a certain time, it has to be delivered at that time. It has to be delivered in 12-point bold face type; if it is delivered electronically, it has to be delivered with that font.

The UETA and E-sign have three main precepts. First, electronic records and signatures cannot be denied legal force or effect solely because they are in electronic form. Second, if the law requires a record to be in writing, the electronic record satisfies the law. Third, if the law requires a signature, an electronic signature satisfies the law.

Both UETA and E-sign only allow for the use of electronic records and signatures when both parties to a transaction agree to their use. In other words, one party to a transaction cannot unilaterally decide to do business electronically, although a party could refuse to do business with you if you didn’t want to do business with them electronically. But they can’t tell you, we are doing business electronically here, here we go.

Second, the elements of an electronic signature are the same in both statutes. The electronic signature is any sound, symbol or process that is made or adopted by the signer, where the signer has the capacity or authority to sign and the signer intends to sign or adopt the signature.

Third, in order to have the benefit of this equivalence of non-electronic records and signatures with paper records and signatures, they have to be able to be reproduced accurately and be accessible to all who have a right to access them. For example, one cannot inhibit printing of such records. Not only will the underlying statutory requirements not be met, but the admissibility of the record may be adversely affected if one provides the electronic record in a manner that impedes the other party from retaining a copy.

The relationship between the pre-emption provisions of E-sign and UETA are worth noting. E-sign was passed by Congress before most states had enacted UETA. Congress sought to jump start the e-signature process by pre-empting any state laws that were inconsistent with E-sign, thus amending thousands of state laws as well as federal laws. However, Congress did not want to discourage states from adopting UETA, and therefore exempted from pre-emption any state enactment of UETA as reported by NCCUSL. It continued however to pre-empt any state enactment of UETA that varied from the reported version, and any other state law that was inconsistent with the E-sign act.

Of course, with respect to federally regulated records such as federally mandated disclosures that must be in writing and required to be provided by private parties, the only general federal law that applies to private transaction is E-sign. So if you are engaged in a mortgage transaction, for instance, and want to deliver the truth in lending disclosures electronically, you can only rely on the provisions of E-sign.

While Congress may grant authority to federal agencies to establish rules for electronic records that go beyond and vary from E-sign rules, this would require specific legislative authority. That was the subject that was discussed when I happened to come in at the end of the last discussion. I along with some colleagues wrote a book called The Law of Electronic Signatures and Records. We have several pages in there that I was sharing with Geff that deal with this question of whether the subsequent federal law can override E-sign. I will provide those pages for the record. I have a fairly long presentation, and I don’t want to re-plow that ground with you at this point, if we can avoid it.

Of course, the E-sign rules are designed to apply only to transactions, not to governmental filings or other relationships with state or federal governments. Where the government itself is a party to a transaction, it may set rules under which we use or allow electronic media, even if those rules differ from the requirements of the E-sign act.

Now, UETA and E-sign have wide application across many areas of law in most transactions. To accomplish this goal, it was necessary to have broadly worded statutes. However, this flexibility comes at a price of concrete guidance. E-commerce laws tell you that you can do business electronically, but with very rare exceptions, they deliberately do not tell you how to do business electronically.

To try to develop some implementation guidelines, the financial services industry developed standards and procedures for electronic records and signatures, or SPERS. SPERS is a cross-industry initiative created by a variety of leading companies and financial services and technology industries. Rather than providing normative rules that must be followed by all entities, such as specifying a certain type of encryption or a given type of server communication, SPERS provides rules of the road that system design teams, ideally an interdisciplinary group of business, technical and legal personnel, can follow designing, building and deploying e-commerce applications. SPERS permits businesses to establish common understanding among internal team members and understanding with outside vendors concerning the methodology for designing e-commerce systems. It assists in establishing industry standards for commercially reasonable enforceable structures and processes, and it helps to provide the consumer with a common experience across online transactions.

In keeping with SPERS’ inclusive goals, it has attracted a wide variety of organizations and points of view. SPERS’ members include government sponsored enterprises like Fannie Mae and Freddie Mac, leading industry organizations such as Wells Fargo, Citi, AIG, Genworth and Charles Schwab, and companies like Verisign, as well as some influential trade associations such as the American Bankers Association and the American Council of Life insurance.

The main features of SPERS . SPERS was designed to provide useful guidance for e-commerce applications and the manual, which is here, is divided into five sections: authentication, consent to use electronic records and signatures, agreements, notices and disclosures, electronic signatures and record retention. Each of these sections provides high level standards, and I have provided a copy of those standards along with my testimony.

Each standard in turn provides checklists to guide an organization’s decision process, along with legal commentary and where appropriate, sample forms that can be used to speed the development process. Today I will give a brief overview of each of the SPERS sections; hopefully some of it will have some relevance to the advice you are hoping to give to the Secretary.

MR. BLAIR: For my benefit, could you just read those five categories again for me?

MR. BUCKLEY: I will. Authentication, consent to use electronic records and signatures. The third category, agreements, notices and disclosures. Fourth category, electronic signatures. Fifth category, record retention. I am going to try to cover each of those separately but somewhat briefly, hopefully.

The first section of SPERS addresses the problem of authenticating persons online. How do you know that somebody is who he or she claims to be? To address this problem, SPERS presents four main development guidelines. These guidelines are found on pages A1 to A3 of the appendix to my prepared comments. You will note that SPERS standards contain several bullet points, each providing more detailed comments on the issues addressed. The SPERS manual as I mentioned provides additional legal discussion of the principles, along with a checklist that can be used to fully explore each issue.

As you will note from the appendix, there are four SPERS standards addressing authentication. First, the standard helps to identify and evaluate the appropriate authentication strategy when creating a relationship, so that is the creating of a relationships phase. The second standard discusses how to identify and evaluate the appropriate authentication strategy when selecting a credential method. SPERS provides a chart comparing authentication methods, including self authentication, third party authentication, positive identification, and compares the strengths and weaknesses of each method.

The third standard addresses how to provide parties information concerning the distribution of risk of unauthorized transactions. If someone is given your identification and uses that in your stead, who is responsible, who is going to bear the risk. finally, there is a standard establishing the authority of representatives to act electronically.

In the context of authentication, a common problem that may — I perceive might arise in the electronic prescription context, is the risk of fraud. Authentication strategies can get used to positively identify all parties involved in the transactions. However, it will also be important to consider the risk of loss if there is a foul-up. There also may be questions regarding the use of credentials by representatives. For example, in your context, would physicians be allowed to provide their credentials to their office personnel to transmit prescriptions that they have written or if not, how will the system validate those transactions? As with many activities, resolving authentication questions will be a balancing act between competing priorities. The system will need to be accessible and easy to use, while still maintaining security and integrity.

The second area that SPERS covers is the consent to use electronic records and signatures. That is contained in pages A4 and A5 of the appendix. There are six standards. First, obtaining a general agreement to use electronic records and signatures. Second, the applicability of e-signed consumer consent process. Third, the content of the e-signed consumer consent disclosures. Fourth, formatting and timing of presenting of e-signed consent disclosures. Fifth, the method and timing of obtaining consumer affirmative consent to using electronic records and signatures. Last, methods for satisfying E-sign’s reasonable demonstration test.

You can see there was a heavy focus on this consumer consent process. In the financial services side of the house, that is rather important, because when you are trying to deliver a federal disclosure electronically, you need to get consumer consent to deliver those federal disclosures under E-sign.

Both UETA and E-sign require the parties to agree to use electronic records and signatures. Under UETA that agreement can be expressed or implied, proven by facts and circumstances surrounding the transaction. Consumer transactions covered by E-sign however require this consumer consent that I have mentioned.

In the electronic prescription context, it may be critical to insure that all parties understand they are electronically entering into agreements to dispense drugs. State regulations governing physicians and pharmacists may play a part in the standards that are adopted. If the standards govern transactions directly involving the consumer, for example, electronic requests for refills of previously authorized prescriptions, there may be a need to obtain consumer consent to do business electronically.

Turning to agreements, notices and disclosures, the third section of SPERS deals with that issue. As I noted earlier, the UETA and E-sign status as overlay statutes does not change the substantive requirement of the underlying law with respect to the method and nature of displaying required information. However, providing such information in a compliant electronic form is sometimes challenging. To help system design teams create a compliance system, SPERS had seven main guidelines, and they are found in the appendix at A6 through A10.

First, there was a discussion of the general principles for display and presentation of information. Then the specific methods for delivering and displaying records and information are discussed. The third standard addresses records and information by other transaction participants. The fourth standard discusses methods of indicating agreement, the fifth, methods of acknowledging access for delivery are discussed, and then the next standard provides suggestions for creating clear and conspicuous disclosures, and finally, SPERS provides strategies for the use of hyperlinks and navigational tools.

An issue that may be of importance to electronic prescriptions is the presentation of disclosures that are required by law and regulation. How will the disclosures be delivered, via e-mail or the Internet, in PDF format or in Word? How do you assure they are reliably set? How do you determine the disclosures have been viewed? Might it be desirable to force recipients to view certain disclosures every time they access the system, or should the process be designed to permit regular users to bypass disclosures that the recipient has previously viewed?

The method of displaying the disclosures online is also important. While the Internet allows a quick and efficient transmission of large amounts of data, an unintelligible flood of information should be avoided. When used thoughtfully, navigational tools such as hyperlinks can highlight information.

Electronic signatures are the heart of electronic commerce applications, and I understand that to be important in the context of electronic prescriptions. To assist users in developing e-commerce applications, SPERS guidelines in A11 through 13 of my prepared comments address the following: Selecting the signature process, then they provide information on assigning process and how you provide information to transaction participants. Third, the standard discusses methods for establishing intent to sign, followed by guidance on how to associate electronic signature with the record. Fifth, the standard addresses methods for attributing a signature to a signer, and finally, SPERS discusses the special rules for creating signatures with electronic agents.

I hope that — I am mindful of the time, and I may be going on.

Selecting the signature process is an important decision. An electronic signature may be any sign, symbol or process, as we mentioned before. This broad definition as the examples on the screen demonstrate that there are a wide array of ways that you can do it. SPERS provides an extensive chart, presenting an analytic took for assessing which signature process should be used. It basically looks at, here are all the considerations, how much security you want, how much assurance you want, so forth.

An electronic signature also requires that the signature be attached to or logically associated with a contract or other record that is signed. Satisfying this requirement can have significant impact on records management systems, a topic that we will talk about a little bit later.

The fifth standard, last, deals with record retention. After a signer has been authenticated and issued a credential, and all the information has been provided and the parties have validly executed the contract or other record, the final step is record retention. EFSC and SPERS have found that this is an area that has not been fully explored by American businesses, and is of increasing importance. The goal is to retain records in compliance with legal and regulatory requirements to maintain them for the proper length of time, to store them so that they are accessible to those who are legally entitled to access, and to keep them in a manner to insures that they will be admissible evidence if they are ever needed in a dispute.

To provide guidance in developing effective document retention programs, SPERS has developed seven record retention principles thus far. They can be found at A14 through A16 of my presentation. They include meeting accuracy, accessibility and retention requirements, verifying the integrity and accuracy of electronic records to prove the design of physical and logical environment in the system is established, verifying there is consistency and integrity of electronic records on an ongoing basis, document conversion, that is, if you move from one technology to another, as you may in some transactions, mortgages may be around as long as 37 years, vendor relationships, interaction with government agencies and finally, transferable records and rules that apply to electronic chattel paper, which is an area of interest to the financial services side of the house.

Electronic record retention is a critical aspect of electronic operations. Setting aside the obvious operational inefficiencies that can arise if records are not kept in an orderly and reliable fashion, there are significant legal repercussions that would have to be kept in mind.

At a conference recently sponsored by the Electronic Financial Services Council, one of our speakers, Ken Withers of the Federal Judicial Center, pointed out the failure to keep electronic records in a manner that helps assure their accuracy and reliability could have significant implications in litigation. Most records, be they accounting records or records in which medicines are prescribed and sent to the pharmacy to be filled, are not automatically admissible in evidence. In fact, they constitute hearsay, a category of evidence that is not admissible unless one can find an applicable exception to the rules of evidence.

One such exception is the business records rule. Under the business records exception to the hearsay rule, a business record can be admitted into evidence even if it otherwise constituted hearsay if it is created and stored in the regular course of business and in a manner that indicates that it is authentic and reliable. Thus, if you are embroiled in a lawsuit and you need to prove that you need to receive a certain prescription, the court may not allow you to bring that document into evidence if you incorrectly stored it in your own system, unless you can show that it was created and retained in a manner that demonstrates its reliability. Your opponent however may be able to admit the document in order to show that even though it was incorrectly stored in your system, they can introduce it as a statement against interest or for the purpose of cross examination or impeaching your witnesses.

To help meet these challenges, electronic prescriptions will need to be stored in a manner that protects their authentication, demonstrating that they are what they purport to be. Document integrity is another critical issue. Some management solutions use electronic signatures to wrap records to insure their integrity. Others use a mixture of logical and physical controls over the database access to insure that records are not altered inappropriately. SPERS contains guidance that allows organizations to parse the issues associated with safeguarding the electronic records.

SPERS guidelines have a broad scope, and they have been put to several uses within the financial services industry. The Mortgage Bankers Association established its MISMO process under which it is creating electronic standards for the mortgage industry, using the SPERS principles. The American Financial Services Association or AFSA has published standards for retail contracting in the automotive finance area using the SPERS principles. The X9 committee of the American National Standards Association or ANSE approved and accepted SPERS in its ANSE X9 technical report. Elsewhere, companies in insurance securities banking have used SPERS guidelines to develop their e-commerce applications. The American Council of Life Insurance and the American Bankers Association offers SPERS to their members through their bookstores and by other means.

As electronic prescriptions move forward, we hope there may be some benefit to the pharmacy industry from the financial services industry’s experience. Although applications and contexts may differ, both financial services and pharmacy industries share many of the same issues in moving their processes online. How do we make sure that persons are who they say they are, that they are authorized to complete a given transaction electronically? How do we insure that all parties have consented to the use of electronic processes to prescribe drugs? If and when consumers become part of the equation, how do we address the unique concerns and requirements of transacting online business with them? Should all or just certain notices and disclosures be provided electronically? What type of security is needed, both in completing the transaction and storing the records, especially given the sensitive nature of prescription and financial records? Finally, how should records be retained in a manner that allows them to remain both secure and accessible and to be reliable evidence in the event that they are needed for regulatory or other legal purposes?

In my presentation I have only been able to hit the highlights of SPERS. The SPERS manual, which is over 400 pages, including detailed checklists and guidelines and so forth, is available. I have attached the guidelines themselves, but if you want to get more, you can go to www.spers.org.

While SPERS was developed primarily by participants in the financial services industry, its principles do have general applicability. It sets out behavioral, legal and regulatory issues that need to be considered in developing any e-signature or e-records process. These guidelines do not claim to be the only or best way of creating electronic records, but they will help anybody designing and evaluating an e-records system. They are deliberately open standards, not endorsing any technology solution, but providing ways to insure the legal efficacy of any specific e-records system.

If the issues raised by SPERS are not addressed, then there is some risk that the e-record system is flawed. By developing these guidelines, the financial services industry provided participants in the e-record marketplace with a common reference point. Rather than each company and industry incurring the not-insignificant expense of developing the criteria it will use to evaluate its and its vendors’ e-record solutions, SPERS gives the company and its internal and external record system providers a common reference point and a common language to evaluate whether the e-records process properly addresses the requirements that create and maintain legally enforceable and binding records.

SPERS for the most part deals with what I call umbrella issues, that is, issues that are relevant not only to a financial services business, but to any business in which e-records are used. For that reason, it may prove to be helpful to you in your work. SPERS can give you the questions you may want to ask about any e-prescription proposals, and provide a basis for open technology natural criteria to be developed in the e-prescription context.

Sorry to have rushed through that, but it was long. if you have questions and if you have time, I’ll be happy to answer them.

DR. COHN: Thank you very much. Maybe I will start with a question. As I am listening to this, it seems that SPERS provides a very useful framework for how we should be thinking about all of this. The question gets to the use case and figuring out how this applies in health care, but I noticed in all of this stuff, you talked about, this handles face to face transactions, this handles non-repetitive electronic transactions. I also noted a place where it talks about repetitive electronic transactions. I am wondering, given that the use case that we are talking about is repetitive electronic transactions, is there any words of wisdom based on all of these —

MR. BUCKLEY: You will have an authentication strategy that you will develop. It may be different in different contexts, but you are going in the opening relationship want to establish clearly that the party you are dealing with is who they say they are.

That may not necessarily be done electronically. It may be that you are going to require the person to come to you with their pharmacist certificate or their license or their medical certificate or whatever, and obtain an electronic certificate that says they are who they are. So you may start out with not doing this online, but doing this in person.

I’m not suggesting that is the way you have to do it. There are ways of authenticating the person that are online through out of wallet tests or other tests that can be done. But it may be that in this context, you will consider it is so important that you will want to do it in person. Then you have empowered the person with their certificate, with their way of doing business with you electronically.

Then you have the question of ongoing relationship and making sure the person — and I think you will probably want to have some agreement regarding how this certificate is going to be used, what the responsibilities of each party are, so that you are not going to have people being neglectful of their certificate and allowing it to fall into hands it shouldn’t be in.

So that process of monitoring and setting up the rules in the beginning, so that everybody understands what they are, and then monitoring the use of the certificate and having a distribution of risks or penalties, or the abuse of the certificate, are going to be other issues that you are going to want to consider. So in the repetitive context, it is going to be a controlling by agreement and controlling by some form of monitoring, if you feel that is necessary as well.

DR. COHN: Jeff, I think you had a question?

MR. BLAIR: Thank you very much. I use stereotypes for shortcuts, and that gets me into trouble sometimes. I have a stereotype about the differences between the finance and banking industry and the health care industry. If my stereotype is correct, then we have a different set of challenges in trying to arrive at standards for electronic signatures. If my stereotype is wrong, then your experience may be helpful to guide us.

This is the stereotype. I have the impression that the banking industry and finance industry has a limited number of transactions, and a lot more homogeneity with its institutions than health care has. Health care is very diverse, not only in terms of the institutions and the settings, but also in terms of all of the different clinical, administrative and financial applications that we deal with.

In the overview that Kepa gave this morning, he pointed out that there is a tremendous diversity of attempts to provide electronic signatures in health care. There are examples of where they are, but they don’t interoperate. So one of the major problems that we will have to probably figure out is not just what standards we select, but how do we craft that in a manner where we are promoting interoperability?

Are my stereotypes about the differences between health care and banking correct, and if they are not, then how did you proceed to develop consensus and interoperability?

MR. BUCKLEY: I think it is fair to say, while some people may think that the financial services industry is quite far along in this area, it has moved ahead, but they are still feeling the way in the financial services context.

Now, if you look at — I am trying to think about your question related to interoperability. In the financial services side of the house, let’s take the mortgage industry, for instance, there are many transactions done with individuals, and it is contemplated that many mortgages will be sold to secondary market agencies. Fannie Mae and Freddie Mac will buy thousands and thousands of mortgages, and they foresee very large savings. But obviously they don’t want to buy each mortgage on a different technology. It may be the technology will be different, but they want to have certain standards met.

So that is why Fannie Mae and Freddie Mac signed up for SPERS, and why the mortgage industry is developing on the technical side their MISMO standards. They want to have what they call smart documents, where they will have a common language, and they will popular the documents with data, but they will have a common language in those documents, so those documents can then be — everybody knows that they are singing from the same song sheet, if you will.

Then there is going to be the question of who owns the documents, where are the documents. The mortgage industry has moved to set up a registry which will keep track electronically of who owns this ethereal electronic document, and it is called MERS.

So there are in the financial services side multiple transactions, and there are efforts to standardize the — there has been a certain respect for technology neutrality, but in terms of spelling out the ways to go about this in a behavioral way, the SPERS effort and the MISMO effort on the mortgage side are examples of how these repetitive transactions are being handled.

One of my colleagues is up in New York today, having discussions with Standard & Poors, who are looking at the acquisition of auto chattel paper. The same thing is the case on the auto side, where the automobile companies are selling their cars. The banks and some of the affiliates of the mortgage companies are providing financing, and the dealers at the dealer level are originating the product. They have to have some schizophrenia there of the method of doing it, in order to make this paper acceptable to the secondary market.

So there are some very strong parallels in terms of the need. I think one of the great problems with E-sign is, it was designed to be a broad grant of authority, and it didn’t want to impose too much, because it thought we would restrict development and advancement and we want to give the broadest grant of authority. There is no regulator to implement E-sign. E-sign is there as a law, but no specific regulator is assigned to implement it. That is probably good in one way, but bad in another. Maybe one of the great advantages of a committee like yours is that you are charged with coming up with some rules, because the lack of rules on the financial services side of the house is probably — let’s face it, large financial institutions are risk averse, and they do move like sheep; they tend to follow their regulator. If their regulator says it is all right to do this, they feel comfortable doing it.

So I think while it is heathy that there be a broad statute without too much regulation, there probably would be faster adoption if there were guidelines out there that were more specific in the financial services industry. That SPERS is really a private effort to respond to this lack of guidance. Each company inventing the wheel, each company spending hundreds of thousands of dollars to figure out how to do it, and then when they get through, they may have a perfectly fine system for dealing with their consumers, but people in the secondary markets say, I don’t like that aspect of it, so I’m not going to buy your mortgage.

So you have really got to have a common language, and SPERS is an effort to arrive at — it doesn’t say it is best practice, it doesn’t say it is the only way to do it; it says, here are some things you have to be thinking about, so that when people are talking with each other, they can say, how do you deal with that issue, that authentication piece of SPERS That gives a common language when you are talking to your vendor, when you are talking to your secondary market provider. You have some basis for common discussion. If you can move in that direction here, I think you will be doing a favor to the e-prescription process.

MR. REYNOLDS: Thanks for your testimony. On your slide ten, you have a significant list of players that participated in SPERS. You have got a big book sitting up there. What percent conformity on this list do you see, now that you have all come up with a standard process and focus?

MR. BUCKLEY: Conformity, did you say? How many are following it?

MR. REYNOLDS: Yes.

MR. BUCKLEY: I think that again, this is in its infancy. The financial services industry people in this room may think it is far along; it isn’t a lot farther along than the industry that you are dealing with. In fact, you will find that the trade associations and the standards setting bodies that are developing the documents that are going to be used by the industry have adopted SPERS, so in that sense it will be populated that way. Freddie Mac and Fannie Mae participated in the mortgage business, they make the rules because they have the gold. So they will be able to endorse SPERS and they are going to see SPERS come out.

We have found that it is being used by many of the companies that are participants in developing their systems, but they are still in the development process. But they are finding it extraordinarily useful, and you can get reports from U-Track and Wells Fargo and Charles Schwab, testimonials at seminars and so forth about how valuable this has been to them as they have implemented their electronic records programs.

In a way, when you say conformity, it is a tool, it is a helpful thing to people. It is not so much, these are rules you must follow, but these are things you have to think about, and if you don’t think about them, you may have a problem. So there is conformity in the sense that people are thinking about this thing.

MR. REYNOLDS: Roughly what would it cost for one of these institutions to go through these —

MR. BUCKLEY: I would not be competent to comment on that; I don’t know. But we have talked about doing a cost study at SPERS, and that may be one of the things we will do as a follow-on, what is the cost-benefit of moving toward electronic records, and secondly, if you do it, how does SPERS help you to do it in a way that is less expensive.

Clearly, it reduces costs by having this as a template or a starting point, but what the total cost will be, I can’t tell you.

DR. COHN: Last question, Steve, and then we will move to the next panel.

DR. STEINDEL: Thankfully, Harry asked most of my questions. The thing that I am foreseeing is, as much as we would like there to be something coming out of this committee that is going to be followed, or from the federal government that is going to be followed, we may be overtaken by events, and the private sector may be moving faster than we are going to move. In which case, in the medical care industry, some type of organization like yours with the private sector point of view might develop a role in that. I was going to ask about penetration, and Harry asked that, and that sounds promising.

But the second part of my question was, how much legal test has your standards or your system gone through? Will it survive litigation?

MR. BUCKLEY: Very fair point. The reason why this is set up, one of the reasons, first of all there is very little in the way of any judicial comment on electronic records and signatures. There is the case in Minnesota, which doesn’t even cite the statute. There are a few cases, but there is very little in the way of judicial precedent, which is another thing that has held back electronic records and signatures, because the naysaying lawyers, and I am one of them, will say wait, I don’t know.

So the idea was, let’s get the best legal minds together and think about what are the problems, what are the issues that could arise. One of the advantages of a system like this if it gets wider adoption is that then the courts will look to that and say, that is a reasonable accepted business practice, and therefore we will cite that and recognize that as being okay.

In the absence of any place where it is all brought together, there is much more risk, but I am just out there on my own. So this response that there is strength in numbers issue and the idea is that we have a commercially reasonable standard that the courts can look to.

DR. COHN: Thank you very much. Do we get a copy of the book?

MR. BUCKLEY: You can certainly get one, but because it is a copyright piece — you can buy one.

DR. COHN: I didn’t need one myself. I was thinking that CMS might want to —

MR. BUCKLEY: I forget what it is, it is only 50 dollars or something.

DR. COHN: We will look on the website then. Jerry, thank you so much. We really appreciate it.

MR. BUCKLEY: Thank you for your patience in my long presentation.

DR. COHN: Our next panel is on network perspective, and looking for Richard Brook and Teri Byrne and Richard Ratliff. I want to thank the three of you for coming and joining us today. Richard, we will let you start with testimony.

MR. BROOK: Thank you. I am Richard Brook, and I am vice president of pharmacy services for Proxymed. Proxymed operates one of the largest physician pharmacy networks today, and has been doing it since 1993. We appreciate the opportunity once again to testify with NCVHS and this distinguished panel.

I have supplied an executive overview of Proxymed’s prescription services for your review. We have had the opportunity to go before several boards of pharmacy throughout the country from Washington State to Florida. Proxymed is uniquely positioned because we act as an aggregator connected to some of the largest pharmacy chains, and act as an aggregator for physician system vendors, and have our own e-prescribing product called Prescribe.

Proxymed participates and is active with several standards and nationally recognized organizations, such as WIDI, X12, ENAC, Edifax, Afact, Mr. Kepa’s company, Claredi EDI, E-Health Initiatives, and NCPDP. Proxymed is very active with NCPDP, and participates in several of the work groups and task groups, and have worked closely with NCPDP in putting together industry’s recommendations. As you will also see, a significant amount of my presentation will be similar to that of my colleagues and NCPDP’s recommendations as well.

One of the main points that Proxymed wants to convey today is the need for network providers to be able to open and reformat prescription messages as part of providing its services for physicians and pharmacists. Although NCPDP Script is widely accepted, there are many versions of NCPDP Script in use, and not all systems have implemented the standard in exactly the same way. Very much like claims clearinghouse services, and Proxymed happens to be the second largest medical clearinghouse today, we often reformat and route claims to payors and deal with many different implementations of X12.

Proxymed’s process though for handling electronic prescription messages are as follows. The messages are created by a system in the physician’s office in the NCPDP standard, and are sent to Proxymed’s network. Proxymed opens the message to determine who is sending the message and where it is to be routed. This information is in the header segment but nonetheless, the message has to be opened. Proxymed performs the appropriate mapping of the message from the inbound format to the format required by the receiver. The essential content — and everybody has to understand that — of the prescription, including the drug specified and directions, are never modified. The prescription is then sent on to the receiver.

So any electronic signature implementation that would restrict the ability for a network such as Proxymed or some of my colleagues to open a message and to reformat its content would severely impact the ability for the network to perform its services. For instance, a PKI implementation that encrypts a message in the physician’s office and requires that the message not be modified in any way while being delivered to the pharmacy would not, given the above processes that are in place today.

It is important that the Subcommittee on Standards and Security understand that the network and gateways have the responsibility of being the trusted party. It is the one that touches the physician’s office as well as the pharmacies, either connected directly into their mainframes or through a pharmacy vendor. It is the physician’s office and the physician’s office system that have the responsibility of both protecting the patient’s privacy as well as the beginning point for the security of the prescription message.

Our current process and procedures of us and the other gateways that are in place have been recognized and approved by most boards of pharmacy. The current boards that aren’t doing this are updating their procedures and policies that seem to work with what we are currently doing and what is in place today.

There is currently a nationally recognized industry standard that is in wide use today, that encompasses using the 128 SSL and encryption security. There have been some discussions surrounding the use of PKI as the infrastructure for the methodology of electronic signature. Proxymed is concerned that if this is adopted, it will significantly slow down the adoption of electronic prescribing. What we do not want to do is add any additional hurdles to the current processes and procedures.

We also have to remember that the physician’s office will be using this for all of their patients, and a lot of discussion has been around MMA and the patients regarding the prescription Part D, but again, if a physician is going to utilize the system, he has to utilize this system for all the patients within his practice.

We also have to recognize that to our knowledge, PKI has not been accepted or deployed in any large scale, and currently none of our partners support this. From the discussions in the industry, we have been told that this will add potentially excessive costs and significant operational changes, and no one is prepared to implement this currently.

First, let’s talk about one of the things I am going to discuss today, a little bit about how a network gets involved, and there will be other testimony from physician office vendors as well on how all this takes place. But first, let’s talk about the physician office system that is in place today.

As I stated, it is the physician office responsibility, where currently they have safeguards in place regarding security and privacy of the patient’s information. As all of you are aware, the other transaction that physician offices currently do today are covered under HIPAA. it is also understood that electronic prescriptions will also be a HIPAA covered transaction. Privacy and security regulations that currently take place in a physician office most likely will occur while that is going on.

There is also a picture in your packet that talks about the electronic flow of prescription, and that is the picture that was put together by myself, my colleagues on work group 11 and 12, regarding the flow of electronic prescription.

There has been a lot of discussion today, and somebody asked the question earlier, how do you know the fax came from the right place, how do you know when you were at the physician office when they faxed it over. It is really what occurs both in the physician as well as what takes place as a network or gateway. Proxymed is very similar to RxHub how we validate and make sure. But I am going to get a little bit more specific about how we do and what we currently do today. As you hear from my colleagues, you will see what takes place today.

I want to talk first about the physician offices and when it comes to that. The procedures that need to be in place and which are currently in place is really during the registration process in the clinic. All systems today should and do require unique IDs and passwords. Within a physician’s practice today, when we work with our customers and we work with our own products, obviously one of the critical things is that people don’t share their passwords when it comes to their ATM, they don’t share their passwords when it comes to anybody else. So when it comes to doing the electronic prescribing in a physician office, that all has to do with the responsibility.

The administrator, the designated authority within a practice or a facility is responsible for maintaining the logons and passwords, and depending on the systems that are in place today, some of them are only able to view certain prescription information about patients, certain people are only allowed to add certain things when it comes to their pharmacy benefits, et cetera.

One of the things that was talked about today, and there has been a lot talked about HIPAA and what takes place, one of the biggest pains is changing your passwords. They want you to change your passwords on a regular basis. We have enough problems now. We try to get smart and add a number after it, the networks and everybody else is getting more sophisticated. So the same thing needs to take place within a physician office when these systems are implemented.

The other critical piece — basically in a physician office all those things are in place, and you will hear more about it from Web MD and Doctor First when they talk specifically about how their systems operate in a physician office. But what Proxymed does as well as RxHub and SureScripts does is, we are the person in the middle. We validate all the processes of the network or the gateway. Everything is authenticated. The question came from Harry today, how do you know where this prescription came from; somebody could have gone to their laptop or their PC and sent a prescription. So when it comes to the network or the gateway in the middle, all the prescribers and the pharmacies are formally enrolled on the network.

Proxymed or the physician office assistant partners contact and speak to all the sites. All the pharmacies are currently enrolled using the NCPDP database, and we are very fortunate in the pharmacy world that there is one unique number, and as we move further into MPI and the things with MMA, we will be in a different position there. But currently today, the methodology used to register physicians on the network is the DEA number. We understand how the DEA frowns upon that, but that is still the one unique way that all of us work in the e-prescribing world today.

So as we move forward and the MPI gets put into place, at that point in time the DEA number won’t be used, and there will be another very good way to validate the health care provider and the health care entity that is sending and receiving prescriptions.

So we credential all the physicians by Resubscribe, as well as my partners do to the DEA database that is updated regularly, and that is how we are able to — unfortunately today, and I say that because none of us really like using it, but that is what is commonly in place today.

So you understand how when a transaction comes through — and you will hear the same thing again. We are here collaborating among competitors, but for the better of the industry, about how we want to get these things done. So as each transaction comes in, so you know who the sender and the receiver is, there is a system ID, there is a sender, there is a receiver, there is a prescriber, there is a DEA number and there is the prescribing or designated agent. All of these things are part of the transaction that is surrounding that information.

All the transactions are checked against the network profiles, and then if the transaction for any reason fails, it is rejected at the network or the gateway that there is an invalid information within that information.

The connectivity today is critical in all these discussions. How do you connect to somebody. There are different ways of methodology today. There is obviously the point to point data circuits, where for example we have a data point that goes directly into Walgreens mainframe. We also work with VPNs, or virtual private networks, which is widely used today and in place. Private dial IP Internet services; all of us are concerned about using the Intranet and the Internet, but this is through an Intranet, through specified phone companies, where there are specific services involved. Using the World Wide Web with the 128-bit SSL encrypted messages.

The messages are only modified as to format. The content cannot be changed. So we need to be careful when we talk about opening the envelope. We are not doing anything with the prescription message. It is just a matter of formatting it. It is only the header inside the envelope that is looked at.

We have seen the industry recommend a definition of electronic signatures, which is supported by Proxymed. All of us are familiar with this, and we have all been repeating the same thing. An electronic signature is an electronic sound, symbol, data stream or process attached, logically associated with a record executed or adopted by a person with the intent to sign the record. Proxymed, NCPDP and the members recommend that the NCVHS adopt this definition of electronic signature as to accept a variety of assurances and solutions that are currently implemented in the industry and accepted by state boards of pharmacy today.

Proxymed also believes and recommends to the subcommittee that the current business practices in place for authenticating prescriptions, which include the user registration and verification processes provided by the trusted parties, with the user sign-on and authentication processes, secure message transmission and auditing process are fully adequate for assuring today the appropriate delivery of the prescriber’s intent to the dispensing pharmacy. This is currently in place and has been for several years.

Thank you.

MS. BYRNE: I am Teri Byrne. I am the director of product management at RxHub, and I am also responsible for definitions of standards and implementation of standards at RxHub. I’d like to thank the committee for inviting us back again. I’m not going to go through what our company does, because I believe you already know.

I wanted to talk about our current practices. You are going to hear that they are a lot like what Proxymed is doing, but we implement the same processes. We contractually require our point of care vendors to have user authentication and authorization, which means they have to have separate user IDs and passwords for the physicians or anyone else accessing the system.

We also do IP address and verification of the sender and receiver, so who we receive a transaction from and who we send it to. We also assign each organization a participant ID and password, and we do verification of the transaction as it goes through RxHub of that participant ID and password.

We speak over secure encrypted channels, so dedicated lines, SSL, the same things that Richard talked about. We also audit every transaction that comes through our system, so we know where it came from, who it is going to, control numbers, date and time, things like that.

Everything that we store meets the HIPAA requirements for protecting health information. The prescriber and the pharmacy are identified in the transaction, based on the Script standards. So we follow the Script standard for identifying both the prescriber and any agents in the pharmacy that the transaction is going to or coming from.

We implemented industry acceptance security controls and processes, so detection logic and things like that, so pretty much making sure that our network is secure.

One thing today, RxHub does not open the envelope of a transaction. We don’t translate between standards, we don’t translate between versions in our production environment. However, we are looking at doing that based on a recommendation and an industry need. NCVHS has recommended that we create the ability to translate between standards, so in the future we will plan to do that. That is really a critical component of how we implement electronic or digital signatures, to allow for translation between standards, so we are going to talk about that a little bit.

We really believe that an electronic prescription today as it flows through the networks from the point of care to the pharmacies is probably more secure, even today, without digital signatures, than a paper or a faxed prescription. There is nobody handling it, it is coming from machine to machine, and because of all of the security processes in the way we are talking over our secure channels, there is less of a risk of that prescription being modified.

I’m going to talk a little bit about the issues. I think you have heard about most of them already, but of course, I have additional opinions I have to always add.

That state regulations are inconsistent and unclear. Obviously NABP and Mary talked about them, and Geff. Prescriptions can be written in a different state than they are filled in, so you don’t have the same standards across all states. You don’t know whether you can receive it or send it, depending on where it is going.

State regulations don’t always consider electronic prescribing, and in some cases prohibit it; we have talked about that.

But the big thing around that is, if you have different regulations or different standards across states, how do the point of care vendors or the physicians or the pharmacies track all of that information and understand what to do, based on where they are sending or receiving information. So that is really a key thing.

Pharmacists today, they are unsure of how to determine authentication of an electronic prescription, so a lot of times they are getting it electronically, they are printing it off and faxing it back to the physician for signature, or they may call the prescriber to verify. It is because of the way they are interpreting the state laws of what is a digital signature, or lack of a digital signature. Then the definition of an electronic signature is not clear. We have heard the definition today of electronic signature, which is definitely different than digital signature, and sometimes people mix those two, and they are a lot different.

So what about digital signatures? I think we have heard a lot of these as well. It can be expensive and onerous to implement them, sharing keys and different standards for them, not one solution today. We believe that if we specify today that a digital signature is required to send a prescription, it will deter the adoption of electronic prescribing. The lack of definition or the lack of standard for that has already deterred adoption.

We believe that we need to be able to support translation of versions and standards or interoperability between standards, but that adds complexity with digital signatures. I’m not an expert on them, but based on what I heard Kepa and others say today, I don’t believe that we would be able to translate between standards or between versions of standards if a digital signature or a hashed digital signature was attached, because the portion of the transaction that would be hashed would have to be opened and translated, even though you wouldn’t be changing the information, you would be changing the format of the transaction.

My opinion is, does that really solve the pharmacist’s concern for non-repudiation? If you have a digital signature, isn’t it the same as having a user ID and password? Somebody could get that digital signature, unless we are using biotechnology to validate that the person that is using that digital signature is the person that it was assigned to. You have some of the same issues as you would just by having ID and password.

The question is, what is the business case you are trying to solve? Are you trying to prove that the physician who is on the transaction actually sent the transaction? Or are you trying to prove that the transaction was not modified during the transmission? Those are two completely different business cases. I don’t think with a digital signature you can solve knowing for sure that it was that physician that signed that transaction.

So what that means is, you will still need to requirement work flow standards for physician systems, the same as you do today with user ID and passwords. We truly believe that someday, there probably will be more sophisticated digital signatures or biotechnology, but we need to be doing electronic prescribing now. If we try to implement it now, there really isn’t a lot of experience out there with it; it will deter it. Once we have more experience and once we get more sophisticated, we could probably implement something like that down the road. RxHub would support that, but today it is just not feasible. We also believe it would require a federal mandate to implement digital signatures nationwide, because otherwise it is too expensive and onerous.

So our recommendation is that NCVHS should recommend the adoption of current best practices as adequate standards for electronic prescribing, and those we talked about. Physician authentication and authorization, so user ID and passwords assigned to a physician. You make participant IDs and passwords for communicating across networks or from person to person. Secure encrypted channels for communications, IP address verification, obviously auditing transactions as they flow through the system, and if they are translated, audited even more. Then to allow translation between standards and versions, because that is going to allow us to be interoperable.

Thank you.

DR. COHN: Thank you. Rick Ratliff.

MR. RATLIFF: I can make this brief. I’ll just say ditto, but some of the remarks were prepared for me, so I will go through those.

I do appreciate the opportunity to talk to the subcommittee. My name is Rick Ratliff. I am the chief operating officer for SureScripts. I have a number of responsibilities within SureScripts, but most notable relative to this discussion is the building of our network and the technology and the rollout and implementation of electronic prescribing across the United States.

So speaking for our organization, I think that maybe I am the right person, or at least, they told me I was.

Anyway, I think you do know who SureScripts is, but just real fast for those in the room, we were an organization that was launched a couple of years ago from the two organizations that represent the retail pharmacies in the United States, namely, the National Community Pharmacists Association that represents the independent pharmacists, and the National Association of Chain Drugstores that represents the chain pharmacies that we all know.

Working with our premiere health care technology vendors, SureScripts has created an open neutral secure system that is compatible with all the major physician and pharmacy software systems in the market, primarily those that are focused around support of the NCPDP standard, as both Richard and Teri discussed. So we definitely are very involved in that standard and the development and support and promotion of that standard.

Today, more than 80 percent of the nation’s retail pharmacies are tested and certified for connectivity into our network, so that is 80 percent of the approximately 55,000 pharmacies in the United States. We began rolling out our network about a year and a half ago, in June 2003, and with our physician and pharmacy technology partners, we are now transmitting electronic prescriptions, so this is from the physician’s application to the pharmacy’s applications. We are not doing faxing, we are not turning anything into paper, we are doing pure electronic prescribing and transmission of those prescriptions. We are doing that in over 40 states.

So we are pleased to say that using the approaches as Richard and Teri have very well described, we have been able to build a network and transmit a very large number of prescriptions electronically in a secure fashion.

So as an organization, we consider the primary stakeholders in this process that have an interest in the confidentiality and integrity of this process to be the patient, the prescriber and the pharmacist who care for those patients. Each of these parties expect that the prescription messages are going to be transmitted accurately and confidentially and with integrity intact. In addition, medical professionals involved prefer that these messages be associated with some type of an audit trail to show some type of level of non-repudiation.

Similarly to what both Teri and Richard have described, we have created a chain of trust from when the prescription is created in the physician’s office, transmitted through the network to the pharmacy, and can recreate that trail when the prescription was originally created to the point where it is stored and processed and then finally provided to the patient and the pharmacy. Again, we are not doing this in a scenario where faxes or paper are being created.

One thing to clarify, and I’ll go a little bit into the process, but Richard did a nice job of going through how the prescriptions are created and move through the network, but just to make it clear, we do not create an end user solution on the physician or on the pharmacy side. So we rely on contractual relationships and some of the technology and processes I am going to describe in a minute to have this legal chain of trust from when the prescription is created in the physician’s office via whatever application they might be using, and transmitted through the network.

We call our network SureScripts messenger services, so I will go into a description of what that is all about. We connect physicians via whatever software application they might be using in their office. We have physicians that might be using electronic prescribing tools that primarily give them the ability to create a prescription electronically. It is a replacement of the prescription pad, if you will, to those individuals that are using electronic health records or medical records, and electronic prescribing is a component of that. We work with those physician partners to implement the NCPDP Script standard for movement of the electronic prescriptions, and we connect their systems into our network via some type of a secure connection. In some cases that is a private network connection and in some cases that is using secure technologies over the Internet. We do something very similar on the pharmacy side, where we connect the pharmacy systems into our network, using some type of private network connection or Internet connection using secure technologies.

Each pharmacy, this being a chain, in some cases the pharmacy chains have built their own pharmacy management systems, but there are also software vendors that represent the 25,000-plus independent pharmacies, is assigned a unique address from a networking perspective to which all of their messages will be sent. So again, this is very similar to what Richard described. We also do register all of our prescribers and our pharmacies that are utilizing the network. In the network there is a process they must go through exactly as described by Richard. We assign an NCPDP ID. Every pharmacy is uniquely identified within the network, as is every physician. So a side note, some type of a national standard for identifying the physicians individually would be a great thing not only for us, but the physicians and the pharmacy partners and can significantly ease the overall process for everyone at this table, and all the stakeholders involved.

We do also validate the prescribers, very similar to what Richard described, against the DEA numbers. We do support the NCPDP message format, so every message that is received from the prescriber or the pharmacy must have a unique ID of both the recipient and the sender of the messages, so this does give us some level of authentication capability.

It should be noted though that a real important part of the gateway is the translation. I think this committee, and I have not been involved in the testimony myself, is very much looking at how can we bridge the HL-7 and the NCPDP standard. We are already doing work with a major clinic in Ohio, and this is well on its way. The network has to have the ability to take that message format coming in via an HL=7 message standard and translate that to NCPDP format to get that onto the pharmacy. I think we all support moving in that direction.

As we look at the information that we store or transmit, we obviously are very cognizant to the requirements of HIPAA. Although none of us necessarily consider HIPAA as a covered entity, our partners typically are, and we do insure that we have the appropriate contractual relationships and business associate agreements where it is necessary.

So these are the processes that we follow to insure accuracy and confidentiality and integrity of the electronic prescribing process, very similar to those that you have heard, and very similar to what you are going to hear or see from NCPDP tomorrow. You will see the diagram that has been created by the work group at NCPDP. We see that this very much is a good representation of the way electronic prescribing is implemented today, and we see that growing.

But ours is one process that at least we believe qualifies for support of what you might term as an electronic signature. But we do know that there are a number of other acceptable ways to implement electronic signatures, and I have to admit, I have never heard an explanation of digital signatures and digital certificates more well articulated than we heard this morning. This is the most complex subject, so that ought to tell us something. It is a difficult thing for us all to understand, so Kepa really helped us to move along the knowledge curve on that one, that is for sure.

We encourage that the subcommittee, very similar to what Teri said, looks at language that is inclusive of a broad variety of approaches. Very similar to what we heard from the NABP and the National Association of Board of Pharmacy this morning, and what we heard from the E-sign act, the terms in the E-sign act, that is the wording that we see in a lot of the regulations across the different states. We are working on some type of a definition and maybe an additional level of clarity around that standard that would help us all relative to getting some consistency across the states, in the way the regulations ar worded and in turn interpreted, because this is part of our challenge too, and that will also give us a platform for education. A significant part of the challenge is education and insuring that all the stakeholders understand and trust that this is a safe system, and that we do understand what electronic signatures are, and we have implemented to those standards.

Since everybody else wants to comment on digital signatures, I will make my comments fairly quick. We are all very aware and very involved in what is happening with the DEA. We really do believe, as do a number of others in this industry, that it is not necessarily appropriate that 85 percent of prescriptions that are transmitted, can be transmitted today, are put to the same criteria or same requirements as those for controlled substances, as what it appears that the DEA is going to promote.

I would say the bottom line is, Simon, as you said earlier, the business case. We all need to be cognizant of that. I won’t go through each one of these bullets, but we do think there is going to be additional cost.

The point that was made in the last discussion around the transaction nature of what we do versus a document, a business related type environment, is significantly different. We are looking at potentially automating three billion-plus prescriptions that are moved between 55,000 pharmacies and potentially 400,000-plus physicians. Having digital certificates and public keys and how you manage all that, I think I understand this much better after Kepa, but I still don’t understand exactly how we are going to do it, if we have to implement this.

I also would say that interoperability is key, and because of the role of the network and the fact that we do need to do that translation, the way that PKI is currently structured in digital certificates and the entire process that is proposed to be implemented, unless there are other types of business models, which is possible, digital certificates would not allow us to effectively continue with the way we are implementing electronic prescribing today.

We have presented to the subcommittee our experience with using the electronic signature process in commerce throughout the process of the last year and a half. We think that what we have implemented does meet the requirements of accuracy, confidentiality and integrity required by the key stakeholders, the patients, prescribers and pharmacists, that we are currently serving in the network.

But with this said, there are a number of ways to implement electronic signatures as we have discussed. We think adoption of some type of language similar to what is in the E-sign act and what is being promoted by the National Association of Board of Pharmacies, maybe with some additional clarity as I said before, might be very helpful.

So in conclusion, I think that is the direction we should go if possible. I appreciate the opportunity to testify, and am open to questions.

DR. COHN: Thank you very much. I know Jeff has questions, and Steve, I have a question, and then Mike.

MR. BLAIR: Rick, you indicated ditto to the other comments. Richard Brook was telling us that it is necessary to open up the prescription because there needs to be some reformatting so that it will comply with NCPDP Script formatting. SureScripts does the same thing?

MR. RATLIFF: That is correct.

MR. BLAIR: Now, this question is to both Richard and Rick. Do you have any circumstances at all where you receive a prescription from a prescriber, where when you open it, you discover that it is already compliant with NCPDP Script standards and you don’t have to reformat? Are there any circumstances where that occurs?

MR. RATLIFF: Absolutely. The current version of the standard that is widely supported is version 4.2. A number particularly of the physician partners who are new, the electronic health record vendors in particular are implementing to the latest standard. So they are sending to us a version of the prescription message in an NCPDP format that is standard. That is a good thing.

The challenge is that the pharmacy on the other end may be at NCPDP 1.5, so we have got to insure that the message content can be read. So it is like, if it comes in via English, we need to get it out in Spanish, so we provide that translation.

MR. BROOK: Yes, and commenting to what Rick said, we have been doing this for quite some time, since the early ’90s or when NCPDP officially became the standard, like seven years ago. Depending on the partners on the network, all the pharmacies don’t move up to the same versions at the same time, as well as the practice managements. So we have to make sure we have the proper information, or the information that is required to be able to validate the message.

MR. BLAIR: Then if that is the case, if the prescriber and the dispenser are both on the same version of NCPDP, would it still be necessary for you to open and reformat the messages?

MR. RATLIFF: Very unlikely.

MR. BLAIR: Very unlikely that you would have to open it?

MR. RATLIFF: I cannot imagine why you would have to do that.

MR. BLAIR: Richard?

MR. BROOK: I believe the same. I would assume that if all the information was on the header for the routing, there wouldn’t be that problem.

Teri is a lot smarter than us when it comes to this technical stuff, but if the information was on the — the way the message is sent, would it be able to route the thing from point A to point B, the answer is that the message would never have to be touched.

MR. BLAIR: If that is the case, and I am just going down a logic path here a little bit, if that is the case, where we had compliance with prescribers and dispensers to the NCPDP Script standards, and they are on the same version, and it is not necessary to open the message to reformat it anymore, what are the other business case issues that we would then be facing if those messages were then sent using digital signatures or PKI?

MR. BROOK: One of the first things is what Rick spoke about before, about mapping from HL-7 and NCPDP Script, would be the critical one, because in order to be able to get the stuff in the proper format and the proper field, you wouldn’t be able to do that without taking the information that way.

MS. BYRNE: I’d like to comment on that too, Jeff, being an organization that does that today. The difficulty is that everybody that you are working with has to be on the same version, which is hard, because not everybody can move to the same version at the same time, or wants to, because they don’t always want to take advantage of the additional functionality that is in the next version. What you end up having to do is this big bang version implementation, which is very risky.

MR. BROOK: One of the things that was also discussed is the version control, knowing which receivers and senders are in which version of the software, so that you would be able to know from looking at the outside of the envelope what would take place, so there would be less of the quote-unquote reformat.

MR. RATLIFF: In an ideal world, Jeff, the message content — taking it where I think you may be going a little bit further, what I heard with HL-7, and I don’t believe NCPDP is quite there yet, however we can get it to an XML type definition, we could actually digitally sign the component, which would be the drug information. That piece might be easier to standardize versus some of the other information surrounding the actual message. That is a possibility.

In an ideal world, if everyone was in NCPDP, you would not have to open the message up because the sender and receiver ID information is in the header. That is what you need to route it.

DR. STEINDEL: I think my question was very similar to Jeff’s. I have another question as well, so keep me on the list, Simon.

DR. COHN: This is your time.

DR. STEINDEL: Okay, I will do both of them. The first one is really a clarification question, concerning this whole idea of opening the message.

Richard, you made the statement very clearly that all you opened is the header. Then I got very confused about that, because I was wondering, how could you modify anything else if you don’t open what is inside. Now I am hearing very clearly that you do, which is fine.

MR. BROOK: Yes.

DR. STEINDEL: I wanted a clarification question on that. That gets me to the point of preparing. When you state very clearly all you do is open the header, you obviously don’t deal with this mismatch of standard issue.

MS. BYRNE: We have to require that all the participants that work with us support the same standard, and currently that is Script 4.2.

DR. STEINDEL: So you do that by business arrangement.

MS. BYRNE: Right. We certify everybody in our certification environment, but when we put them in production, we only open the header for routing information.

DR. STEINDEL: That makes total sense. Now it all fits together.

MR. BROOK: Let me just the other point. The retail pharmacies today — and I don’t believe Teri is directly connected to any retail pharmacies — the retail pharmacies are in all different versions of Script.

DR. STEINDEL: No, it makes total sense to me to have to open the envelope and reformat to translate between versions, et cetera, if that is a business requirement. I was just very confused when you said you didn’t open the envelope.

MS. BYRNE: Just so you know, having this model for us has prevented us from implementing some of the new versions of Script, because all of our systems can’t move there yet.

DR. STEINDEL: My second question is addressed to all three of you. The sense that I am getting is that there are — you are talking about a requirement with regard to signature in the electronic world that is somewhat analogous to what we are seeing in the written world, that kind of authenticates at whatever level — it is a relatively minimum level in the wet signature world, but maybe a little bit stronger in the electronic world. But roughly equivalent that says, yes, this person is the right person who ordered this prescription, and I am going to go ahead and dispense it, and you would like things kept at roughly that equivalent level.

The next issue that I have is, you talked about audit trail, and what we heard about before was traceability. There is an issue of the prescription today, and issuing it, and then the consequences of what happens with that prescription sometime in the future, whether this was a duly authorized and issued prescription, which gets to the idea of traceability and audit trail on all ends of the process.

Do you have any idea how long that information should be kept and what format it should be kept in, and how are we going to deal with that question? We can be dealing with litigation on drugs 20 years from now.

MR. BROOK: Let me address first. Individual state boards of pharmacy are the ones that require different things. Of course, when it comes to controlled substances, there are federal mandated lengths of time. The pharmacy systems networks like ourselves — we run into issues with boards of pharmacy, where we are the network in the middle, and they say we can’t keep the message, but we have to keep the message in order to — what you just said, for audit trails, for fraud and abuse, and to be able to validate later on. It runs into a situation where people say, what are you doing with the data? Are you selling the data? What are you doing with the data?

So what occurs today is that we do keep the message, and we run into problems with boards of pharmacy. I’m not going to single out a board of pharmacy, but there is one of them in the Northeast that was very specific about, that we couldn’t even have a network in the middle to validate and do the transactions. If the transaction went through, it has to disappear. Most systems were built today where in the system, you can’t delete the prescription. We had a situation where somebody was using our network to write prescriptions fraudulently for a friend, and we were able to have that because we had the message. Even though people might think that they go and delete the prescription from the electronic writing system, they really can’t delete within the system.

So I hope that answers your question. It becomes between state law — in the pharmacies, keep the prescription a recommended number of days. So there are a bunch of individual laws and federal laws.

MR. RATLIFF: Most of the state pharmacies need to keep a prescription record for seven years. As Richard was saying, there are DEA requirements.

Remember, we are transmitting prescriptions that are called non-schedule medications. So in that case, we are storing — in our case we are storing in line with the seven-year requirement. The DEA requirements might change that if we are able to transmit electronic prescriptions for controlled substances at some point, which by the way boggles my mind, because if we could do that, just imagine what we could do from a fraud and abuse protection perspective by having the data stored appropriately. So we do need to have the ability to do that.

But when we do store the data, it does need to be encrypted appropriately.

MR. BROOK: But the HIPAA regulations and rules are going to take place when it comes to — when we do that on the claims side, believing that electronic prescribing will be HIPAA covered transactions.

DR. COHN: I have a brief question. Rick, in your testimony you said we believe the digital signatures are not appropriate and necessary for the 85 percent of prescriptions that are not controlled substances.

MR. RATLIFF: That’s right.

DR. COHN: So let me ask all three of you now, I have no idea whether 15 percent of drugs are controlled substances or not, and I have no idea what the DEA may be doing, so you probably all know more than I do.

But I read from this that there may actually be something that is relatively strong, a signature or something like that from DEA. So are all of you advocating for a dual standard, where there is a harsher standard for DEA or controlled substances and a lesser standard for the other 85? How are we or you going to implement that?

MR. BROOK: The answer is no. We want one standard for everything. We think the DEA may be going a step too far. That would be the situation.

What Rick was referring to was 15 percent of all drugs today are schedule two or controlled drugs. However, we are concerned — and what happens today is, most software applications today when it comes to controlled substances automatically print out the prescription because they know by the controlled substance of a drug which the drug is.

So like Rick was saying, if the DEA forces us to do this for 15 percent of those drugs, they won’t be transmitted.

MR. RATLIFF: That is they key part of it. The 15 percent actually refers to schedule two through five. Schedule two are about two to three percent of the total.

So the concern is, yes, they absolutely are going down a path of a stronger authentication. They are getting very proscriptive on the process and very proscriptive on the solution as we understand it. Obviously the regulations haven’t been published, but it does appear to be some type of a PKI or some type of a stronger authentication around a token biometric, at additional cost and additional complexity in the process.

The challenge is, and we heard this this morning a little bit, if that is required for 15 percent of the medications, it is likely as the number of boards of pharmacy are working today, they are waiting on modifying their regulations to see what the DEA says. I can tell you, many of the boards of pharmacy, not understanding there is an educational issue here, are looking at that, and that can be the new standard. If that is the new standard, then that is going to slow down the adoption of electronic prescribing. So we are not promoting a stronger authentication necessarily.

MS. BYRNE: The last presentation I have seen is a couple of years ago, so it would be interesting to find out what experience the DEA has gained in this area. But I haven’t heard anything.

DR. COHN: I really have no knowledge. I think what I am hearing from all of you is that you don’t want two different standards for electronic and/or digital signature. Whatever it is you want, you want one standard, and that is probably the most important thing you said.

MR. BLAIR: We have here our three largest networks, and from what you say, NCPDP will be sharing and echoing your concerns. The message has come through very, very strong that you feel so strongly about the negative impact of using PKI in digital signatures that you would wind up not having them on your network, and it would slow up the acceptance of electronic prescribing. So I sense the intensity of your concern.

Now could you help me understand what is behind this deep concern, apparently either the magnitude of the business case, or the technical issues must be pretty severe that you would be taking this position. Could you help us understand why this is such a big cost or a big technology problem, or both?

MS. BYRNE: Jeff, first of all, I want to make a clarification. There is a difference between PKI and digital signatures. PKI encompasses a lot more than digital signatures, encryption and other things. Industry does use a lot of different aspects of PKI.

In my testimony, I was talking about digital signatures, just digital signatures. It is very expensive and administratively onerous to implement. It is the issue of the keys between the physician and the pharmacy or who has the keys and who distributes them and how many keys are there.

Again, one of the biggest things I believe is a problem is, we can’t translate. We can’t translate between versions and we can’t translate between standards, which is something that has helped move the industry along just recently. So I think we will go backwards if we try to implement something like that. Or you have to figure out a process where you can allow a translator to understand the signature and refine it or something, I don’t know. Kepa is shaking his head. I don’t know, there are just a lot of unanswered questions around that.

MR. BROOK: Again, somehow PKI is getting singled out in understanding the complexity. I’m not the expert, you have the expert sitting behind you, Jeff.

But what we understand as far as the magnitude, the technical piece of this, the costs involved. There are so many things that are unforeseen when it comes to that, and somehow PKI just got off on the wrong step. I have heard Kepa and other people speak about it for several years.

So we just feel strongly about the reformatting and the interoperability when you get involved at that level, is that correct?

MR. RATLIFF: My comment on that is that it goes to the complexity of the implementation, number one. We do have to address some of the questions, as Teri just mentioned. Do we have a single certificate authority, do we have multiple certificate authorities, do we have a root certificate authority, a subordinate certificate authority. This is going around and around and around. If it adds a significant level of additional security and level of non-repudiation and those types of things to the network, and tradeoff to the cost — I’ll go back to what Simon said earlier, then absolutely we have got to consider that.

My concern with this also would be scalability. So it is complexity, cost and then can it scale to a transaction type network like we have. Is every prescription digitally signed? Some of your questions you were asking earlier, Jeff, I think there are a lot of unanswered questions there, and likely from a pilot perspective, maybe we should find a pilot where we could implement something like this and see if you could standardize the approach, if you could find an interoperable solution, if you can find a solution that will scale. Unless you can do those kinds of things, then we have enough challenges with getting physicians getting the right infrastructure to buy an electronic prescribing solution, much less an electronic health record like the President would like for them to have, and those type of issues. And now to have this additional level of complexity and cost, then we view that as another challenge.

The next piece related to cost is going back to something Teri said earlier, is the fact that really, my understanding in talking to my technical team is that the digital signature is only as good as an ID and password still. Unless you have something that is tied to it, and something that is unique to the individual, so something like a token or a biometric kind of authentication, and biometrics are not standardized yet. We have still got error rates with biometrics.

So I think we have a number of challenges to figure out what is the right architecture and approach.

MR. REYNOLDS: Teri, if you look at slide two, about halfway down you talked about where the prescriber and pharmacy are identified in the transaction and that is as secure, if not more, than paper and fax. Then if you go to slide three, slide three may be general comments, but pharmacists are unsure how to determine authenticity.

So on slide two, you are saying you feel very comfortable and you have identified both of them, and on slide three you are saying that they don’t know how to know who it is.

MS. BYRNE: Slide two is what is done today, and slide three is what are the issues today in the world of pharmacy. That point I am making, about pharmacists being unsure how to authenticate or determine the authenticity is because of the way some of the state laws are written about what is an e-signature; is it okay if the user has been authenticated, and then they put their mark on it as a name or a DEA number or whatever on the transaction, or do you need some kind of digital signature.

It is really the interpretation that is at issue, which is causing them to go back and call up the physician or ask for a signature.

MR. REYNOLDS: You are saying that what you have in place meets a good security level, meets a good identification level; it is just state laws and other things.

MS. BYRNE: Right, it is the interpretation of those laws, I think.

MR. REYNOLDS: Okay. Richard, you mentioned how you stamp each transaction to identify who it is. When you get to the private IP on the web, and somebody gets into your system through the web, how are you identifying the ID then?

MR. BROOK: When they are on the web it is through an Intranet, it is not through the Internet. When they are getting on, we are giving the IDs and other things that validate the information going back and forth. So it is a private Intranet, it is not through the World Wide Web.

MR. RATLIFF: In our case they are coming through the Internet. However, there is a specific IP address that is assigned to each sender. It is either secured via a secure socket layer, I believe it has been mentioned, a 128-bit encryption, as the messages move over the network, or there is some type of private network connection, which is almost like a point to point connection over the Internet.

MR. REYNOLDS: Is that associated with their laptops, with their offices?

MR. RATLIFF: In our case, in most situations that is associated with a single host server, if you will. So most prescriptions are coming — if it is an electronic prescription, then that electronic prescription could be created by an application that is on the Internet, and they may bring their browser up, and they can have a secure connection between their laptop and the application. Like you do with a website today, if you go to amazon.com and you type your payment information in, they create a secure connection.

That is the way the application vendors work. You write your prescription, and it is saved on their central site. We have a connection from their central site that stores that prescription to our site, but not from every end user.

MR. REYNOLDS: My last comment, Rick, I think it was you that mentioned that you guys really don’t fall under the HIPAA statutes right now.

MR. RATLIFF: We don’t fall under what is defined as a covered entity. We do view ourselves as falling under the HIPAA statute.

MR. REYNOLDS: Let me throw out a concern I have. If you take the transaction and open it, that sounds an awful lot like a covered entity under HIPAA. Richard, back to your comment, if we think this is going to fall under HIPAA, the minute you pass it on, you may have a defensible position.

As a member of the committee, I would want to make sure that we consider that, because once that is open, and once that PHI is invaded with the software, then I think you are going from one standard to another. You are into the PHI, you are clear. That is one thing I would like to make sure we keep clearly in mind as we go forward.

DR. COHN: Very good point. Mike and then Stan.

DR. FITZMAURICE: All these questions have been very good. Mine is a more general question, just to make sure we are on the right track. I see there is a lot of translation, and you want to avoid the need to translate electronic signatures across different certificates. We are going to be hearing Friday that the patient sig would apparently need to be translated, the formulary information will need to be translated, and HL-7 information will.

All of this translation takes resources in the short term, but in the longer term it opens up markets. The proprietary standards can establish a competitive advantage for a particular firm. The cost of translation is formidable, but we may have open standards and everybody using the same standard, then often headers can reach everyone’s customers.

Are you afraid of that? Do each of you support the development and implementation of the more resource intensive electronic signature, the patient sig and the formulary standards for use in your application? Then does that extend to a national provider identifier and a national health plan identifier, too?

A more general question is, are we moving in the right direction? Is there anything that NCVHS could do to encourage this movement if it is in the right direction? So are you afraid? Do you welcome it? Do you see it as reducing the wedge in the pie but increasing the size of the pie for everyone? How do you look at this?

MR. RATLIFF: We definitely view the standard as being extremely important. If it wasn’t for the standard and some type of an open systems type of approach to this, I don’t think we would be where we are today.

The pharmacies — Walgreens is connected to my network, and they are connected to Richard’s network. They are connected to those networks using the same type of connections and using the same type of messaging standards.

The challenge is, Walgreens and CVS and others have 4,000 to 5,000-plus stores across the United States, and they need to have the business case to move into that next level of the standard. If we could promote to a free market position, if we could get the level of electronic prescription transactions from the current one to two percent of the total volume to 20 to 30 percent of the total volume, we will have the drive to get to the standard.

If you look at what Walmart has done as an example on the supply side, you probably should take a look at that, because the volume is where it is on the supply side, and while those standards are moving in that direction, there have been supply exchanges. Walmart has now moved away from clearinghouses, it has opened up other business opportunities. But there is a standard called AS2 that allows for the secure transmission of documents for commerce for the supply side of Walmart. They require that from all of their partners.

Now, obviously they have a little leverage in doing that, but industry also has some leverage. The industry wants to drive the standard. The industry supports — the PBMs or the pharmacies, I believe they support NCPDP as an example, and that is what we are pushing and promoting.

Our challenge is seeing if we can translate some of our — because I actually come from the hospital/health care side of the world; if we can help our health care partners with HL-7 and get HL-7 to a real standard potentially, and get some of the translations there, then we can get some more interoperability, just from moving information around.

So we have got a number of challenges, but it is the standards themselves that helps us to move the information. That is the only way we are going to get this done.

MR. BROOK: One of the things that I can tell you from our experience in the past, we thank God for standards. Being in the claims clearinghouse and prescription business, when we started doing electronic prescribing years ago, there was no Script. Then we got to Script, and the slow process moving to Script, and right now, everybody that is connected to our network, either from the front end and basically the back end now, we are doing Script standard. We promote that in the claims side. When I mentioned to you Edifact, Enac, WIDI, X12, that is what we have to do. Without going to the standards, the costs involved to keep up with every Tom, Dick and Harry are unbelievable.

So we welcome that. Of course, in the marketplace if everybody is on the same standard, they could take the same pipe that I am communicating with Walgreens and put it someplace else, or my pipe could leave and somebody else’s pipe can go on. So sure, there are some business cases in the beginning, where saving on proprietary stuff is good. However, for the sake of this industry, for the sake of doing electronic prescribing — part of NCVHS’ recommendations to HHS about doing additional transactions like Rx Fill and all those things are bringing new opportunities. Even though if you use the standard and implement Rx Fill, you are still giving people advantages if they are as good or better at implementing different transactions that would be part of MMA or things like that. So we welcome that entirely.

MS. BYRNE: But I do want to clarify one thing. RxHub is doing translation between other standards, formulary, medication history. When we are talking about electronic signatures, we are really only talking about new prescriptions today. So that is the scope of what our testimony is around.

The other transactions that we are transacting are going through the same secure pipe that our new prescriptions are, but as far as digital signatures, I think the scope of that is just for new prescriptions.

DR. HUFF: I just want to clarify and then ask a couple more questions to make sure I understand. As I understand, especially, Teri, from your testimony, what you are saying is, your business process is that you institute policies and procedures that say people have to have logins and passwords on the systems where they are prescribing, and given that that is in place, then the rest of what you need to do — basically when you see the person’s ID in a transaction, then assuming that those policies and procedures are in place, seeing their ID is sufficient electronic signature for the purposes that you are using it.

MS. BYRNE: So their DEA number or whatever. We don’t passe the user ID in a transaction. It is just the identity and the main address.

DR. HUFF: And that was a clarifying question. You are not physically passing any passwords in there at all. The assumption is that, to get to the point where they could put that ID in a message, login and password identification, and from that point it is passed in a secure network and other things.

MS. BYRNE: But we don’t pass the user ID for the physician or the person that logged onto the system. However, we do have an ID and password that we have assigned to our participants. Like SureScripts, we communicate to their central location, and that application has an ID and password with us. So that ID and password is in a header, and we do authenticate that.

DR. HUFF: I guess the next question would be, do you have policies and procedures in place to actually go out and verify that those things are being followed? Or what are your thoughts, how would you know if somebody was abusing that, or shared their password or other things? Do you have any way of verifying?

MS. BYRNE: We contractually obligate the point of care applications to do that. But we also have, depending on RxHub’s contractual model, either RxHub or the ends will certify the applications. That is part of making sure they have user authentication.

DR. HUFF: And in most of the systems that you know of, how are they administering that? Are they administering the password centrally, or are they allowing end users to change their own passwords? Or you haven’t been concerned with that level of policy?

MS. BYRNE: I just can’t speak to that.

MR. BROOK: I think you will hear more testimony tomorrow from Medical Manager, Web MD and some of the others. Talking about Prescribe, our own application to get access to the network and gateway, yes, there is a system administrator that maintains and manages the logons and passwords for the people that work within the practice. You could use certain information, depending if you are somebody up front that is entering the patient demographic or somebody that is entering a prescription. So depending on how systems are set up, it can get more complex.

What I mentioned in my testimony, that stuff or that information is really the responsibility of the physician’s office. However, we are certifying with that software to make sure that it meets some of these requirements.

MS. BURKE-BEBEE: The panel talked about concerns, arguing against digital signatures, higher cost, scalability, interruption of work place. But you said one more in your testimony, which has to do with prevention of interoperability. I wonder if you could elaborate so that I could understand better how encouraging NCPDP and HL-7 to harmonize and the e-prescribing would invalidate the digital signature, just so I understand it.

MR. RATLIFF: When a prescription is created, and I’ll use an example of a clinical system that communicates via HL-7, they create an electronic prescription in a clinical something in a physician’s office, and it is formatted via HL-7, so it is an HL-7 message. The physician then digitally signs that, goes through the process we heard this morning, and the digital signature is attached to that HL-7 message.

When that message is received by our gateway or anyone else’s, and it needs to be translated to NCPDP format, it has to be opened up. Remember, the hash is specific to the message, so when we translate it to NCPDP and we restructure the message, it is my understanding that completely corrupts the hash, which completely corrupts the digital signature, which then would say — because we have changed it. Although the content of the prescription is not changed, the format going out the other end to the pharmacy as an example is different.

So the actual prescription information comes in via Spanish and we translate it to English, so if it came in via a document that was formatted such, when we translate that, once we have touched it and we have modified it in any way, that digital signature is no longer valid.

Now, the one thing that could happen, and we have talked to the DEA about this, is the possibility that there could be trusted third parties, and trusted third parties could act on behalf of certain entities in the network, and we could be acting on behalf of the pharmacies, as an example. In this case, we would authenticate the digital signature coming in, we would reformat, we would resign it and send it out the other side.

Now, that is a possibility, but again, that is complex, it adds infrastructure on our side, and it adds a significant amount of development and cost and change of work flow in the pharmacy as well. So that is our interpretation of that particular issue.

MR. BROOK: We are going to get Rick a job for Claredi later on working with Kepa. He did a good job explaining it.

DR. COHN: Do you have a final comment or question?

DR. STEINDEL: No, I actually have a comment. This goes to a lot of the statements that were made about the complexity of operating the digital signature system, et cetera. I think we have heard presented in other venues and NCVHS in other areas, CDC has actually operated what we call a secure data network for at least four years, for transmission of confidential public health information between our partners, on the public Internet. The things that you hear today about information about flu vaccine availability, and CDC is monitoring this, blah, blah, blah, that information is going across as secure data network.

We can go into details, but it is basically double encrypted. We are the certifying authority. We are working in a very circumscribed area with public health partners. Everybody has a token, so we do the very strong identification. We can do it in that circumscribed area, but magnifying that would be very difficult.

So this is basically an example that is in support of what people are saying. It can be done in a defined circumscribed area, and done very well.

MR. RATLIFF: I would just like to reiterate, there is no doubt there are abilities to implement that kind of an infrastructure and that kind of an approach in the right environment, and there is a business case for that.

DR. COHN: With that, I want to thank the panel for what has been a very interesting session. We will take a 15-minute break and come back at 3:30. Thank you.

(Brief recess.)

DR. COHN: Our next session is on the industry collaborative called Secure Access for Everyone. Ashley Evans, you are taking the lead, and Paul Donfried, you are providing the backup, is that right?

MR. DONFRIED: Technical Q&A.

DR. COHN: Thank you both very much for coming.

MR. EVANS: Good afternoon, and thank you for the opportunity to testify before the Subcommittee on Standards and Security, with the specific focus on the topic of electronic signatures.

My name is Ashley Evans. I am a partner with the strategic identity group. I am a founder of SAFE, and I represent — I am the chair of the business model working group that basically makes the fundamental decisions around how SAFE from a government perspective works, and what the business plan is, going forward, for SAFE.

I’m not going to go through my bio, even though it is in here, I won’t bore you with those details. For the last three years, I have been focused exclusively on the development of SAFE, working for Pfizer and for Merck in that activity. I testify before you today on behalf of the SAFE initiative specifically. I don’t represent Pfizer, even though I work for them in this activity.

This afternoon, I will provide an overview of what the SAFE standard is, why it was created, and how electronic prescription will leverage the SAFE model for both e-prescribing and more broadly throughout health care. What I would like to outline first is YC SAFE and MMA and where the interests meet and essentially take you down the path of how SAFE can apply to those needs.

In June 2004, the President’s Information Technology Advisory Committee published a report revolutionizing health care through information technology. The report stated that, and I quote, a robust national health information infrastructure will require a firm foundation of trust. Americans must be assured that their confidential health information will not be misused, and that there are adequate legal remedies in the event of inappropriate behavior on the part of either authorized or unauthorized parties. Furthermore, the report goes on to state that, health information can only be accessed with adequate security and privacy if there are a clear means for verifying the identities of those accessing and altering data. The lack of defined standards for security and the lack of an accepted hierarchy of trusted authentication agents impedes the development of the National Health Information Infrastructure and associated cost effective data communication systems.

In essence, trust is a fundamental premise within which SAFE was created. I referenced the previous quotes because they stem from the following MMA requirements, and they are directly aligned to why SAFE was formed, specifically, to support interactive and real time transactions, comply with HIPAA and privacy and security regulations, and to be compatible with other standards.

SAFE is required to include quality assurance measures on its systems, improved efficiency including cost savings and I will talk briefly about the extensive business case that we have created for SAFE for the pharmaceutical industry, not present an undue administrative burden on prescribers and dispensers, and for SAFE to be vendor neutral and technology independent.

Although we will talk about the business case independent of the benefits of SAFE, we believe there is immediate value to health care based on a shared experience SAFE sponsors have evolved over the last few years. In essence, we are co-dependent as an industry to deliver a scalable firm foundation of trust, and to insure that where applicable, we can verify the identity of those accessing and altering data.

SAFE is a young standard. Officially we were formed in November of 2003, but it is a dynamic and evolving standard that has seen significant change in maturity from version 1.1 which is where we are now in production to version 2.0, which we will be publishing in 2005. We are committed to continuing to evolve and enhance SAFE to meet the requirements of the health care community as it adopts electronic record and electronic prescribing. Our mutual challenge today is to determine what components of SAFE and other standards recommended by NCVHS can be leveraged and applied to solve electronic prescribing requirements.

With this question in mind as you review and hear my testimony today, please consider the following. SAFE was developed with the same business and end user objectives that the MMA is pursuing for its e-prescriptions and e-records. SAFE participants are interested in furthering the dialogue within NCVHS, HHS and others such as NCPDP, to review where all or parts of SAFE can be leveraged or enhanced to meet MMA requirements.

The SAFE user community overlaps with the broader physician community that you have heard about today with the drug prescriptions. SAFE is based on open standards, using existing and commercially available products for implementation.

Some background on SAFE, how we came together and how SAFE came to be as we are today. In 2002, the biopharmaceutical industry sponsors came together to begin the process of determining if a meaningful business case existed for an identity assurance standard within the pharma sector. Although industry had made progress on many electronic information exchange standards, the fundamental component that was still absent at that time was trust. By trust, we simply mean reliably establishing the identity of the party with whom business is being conducted.

It took the industry less than four months to determine that establishing an identity assurance standard under a shared cost model was essential to removing the paper-based records constraints that were plaguing the industry. Consider back then that the business case we were looking at were six million pages of paper per drug that was getting to production through the FDA. So the paper-based constraints were forcing some issues in the business process, and were costing the industry too much money.

In 2003, the SAFE coalition was formed and sponsored by PHRMA, including leadership and resources from 13 biopharmaceutical companies. At the bottom you will see the names of those companies in my testimony. Leading companies such as Merck, Pfizer, Amgen, Lilly, GlaxoSmithKline, Bristol-Myers, the usual suspects in this industry, with development, contribution and government oversight from the FDA, which still exists today.

The SAFE initiative has been focused on the creation of an identity assurance standard to be used by the biopharmaceutical industry in business to business and business to regulator transactions, and consider SAFE credentials to be used for electronically signed documents from molecule all the way through drug delivery participation. Sponsors will be using SAFE to apply to those kinds of transactions in the commercial sector today.

It is worth noting that although SAFE sponsors are focused on the research, development and information supply chain, SAFE has been developed to be ostensible across the health care sector along with other trust infrastructures, to be co-dependent.

So what is SAFE? Secure Access for Everyone. What is the standard? The SAFE standard is based on open standards such as ITU, X-509, FIPS 140, IETF, RFC. The technical trust infrastructure is based on use of digital signatures that will be certified by trusted third parties such as regulatory and financial institutions. This trust framework is also based on PKI bridge architecture, something that provides technical interoperability between previously separate or isolated trust domains.

As an example, SAFE’s bridge architecture has been develop and issued to allow for trust certification with other public key infrastructures. This architecture also allows SAFE participants to leverage existing investments and their PKI by acting as their own issuer. An example in that environment would be Pfizer as an organization has outsourced its PKI or certification authority to a trusted third party, whereas Johnson & Johnson in the real world has actually built their own. How do those two entities interoperate in that environment? SAFE solves that problem, it provides that bridge.

Fundamental to electronic prescribing in SAFE is the ability to verify the identity of the physician and the pharmacist engaged in the prescribing process. SAFE standards include a set of business policies and procedures, operational guidelines and technical specifications. The standard set defines the elements necessary to manage the complete credential life cycle, apply e-signatures to a document, and technically deploy and operationally deploy SAFE credentials. The key elements of the standard that we thought may be of importance today include high security. The SAFE standard provides for strong security and data integrity through the use of two-factor authentication tools combined with public key cryptography. SAFE security specifications embrace international standards and best practice to insure ease of integration into user systems and applications.

Legal effectiveness. SAFE credentials and the digital signatures they create are designed to be acceptable for use in data collection and exchange, development, authoring, review and approval of regulatory documents and filing processes. This is accomplished through a contract structure through which parties agree to abide by the technical and legal components, as well as the operational components of the SAFE standards. Finally, regulatory compliance and acceptance. Just recently, SAFE has published as the e-signatures solutions to meet the goals set by the FDA for a common standard e-signature solution in the pharmaceutical industry.

SAFE standards have been designed to meet various regulatory, operational and operating compliance guidelines such as those specified in 21 CFR Part 11 and HIPAA and other similar local and regional regulations. So we have now got the standard on one side, and there is an organization that needs to operate, manage and maintain that standard.

SAFE is a member regulated, not-for-profit enterprise. SAFE Biopharma LLC intends to operate as a shared cost platform for the benefit of all of its users and members. The role of the organization is to manage, maintain and enforce the standard, provide a legal and contractual enforcement framework, provide the necessary technical infrastructure to bridge disparate credentialing systems into the SAFE environment, and provide the channel via contracted accredited issuers, the issuance of SAFE credentials.

SAFE Biopharma LLC will also promote the adoption and use of the standard by SAFE participants with other messaging and submission standards. Finally, we support vendor supply of SAFE enabled applications and services.

So the critical question in that context is, if you have got demand for these credential issuance services, this SAFE standard, how do we insure that the applications vendors are ready for the products to meet the standard and to insure interoperability.

How does SAFE work? Operationally accredited SAFE issuers such as regulated financial institutions validate and confirm the identities of legal entities and their employees. Participants enter into agreements to abide by the rules of the trust network. Issuers then provide digital signature credentials for the companies for distribution to their employees. Should users lose their credentials, the issuers manage the systems and the provisioning of the cards or the tokens. In the event of a system or operational failure, liability is associated with the participant or the issuer responsible for the failure. People are accountable for specific elements of the transaction. In addition, the SAFE standard specifies that the issuers insure against transactional liability, something that makes SAFE very different from other trust domains or other trust networks. We have liability assurance specified in our operating role as a requirement.

SAFE credentials can be used to authenticate users and encrypt transactions to any enabled application in the system. Applications are enabled with commercial off the shelf technology to connect applications to SAFE issuers, their validation services specifically. SAFE requires issuers to provide validation response with audit trails and time stamps, specify and substantiate who signed a transaction, what transaction and when. Finally, the SAFE implementation enables the physician or the pharmacist who is transacting with multiple entities to use their credentials with other SAFE enabled participants.

The key question there is, how many networks, how many applications, how many transactions, how many identities to you really expect the physicians, doctors, pharmacists to have, own and to manage, to be responsible and be accountable for.

I will provide a specific example of how SAFE is being applied today by HHS through the National Cancer Institute. You may have heard, a few of you on the panel, previous testimony given by my colleague, Paul Donfried, that the NCI cancer bioinformatics grid is establishing a new application called Firebird. Firebird will use SAFE electronic signatures to automate the process of clinical investigator registration materials participating in clinical trials. Firebird will also eliminate the need for paper and wet signatures, while enabling physicians, their staff, NCI and the FDA to rely on SAFE electronic signatures applied directly to the electronic forms they are in.

Active participation in this pilot includes a number of major cancer research institutions, major pharmaceutical companies and the FDA. It is worth knowing that Firebird is integrated into a broader plan for provisioning SAFE credentials to investigators and their staff globally. It is essentially funded by the industry.

The 13 SAFE sponsors that are funding SAFE have agreed to pay collectively for SAFE credentials for investigators and the investigator community. This is the alternative versus every single sponsor providing a different credential and independent proprietary solution for those same investigators. The ultimate objective there is to remove the complexity and to provide a unique credential to those investigators.

SAFE has also developed issuer accreditation and application ennoblement certification programs. We have been working with the vendor community over the last two years to insure there is commercially available middleware to deploy a common standard and to minimize integration complexity.

SAFE is working with both financial and non-financial institution issuers. We are working with over 40 application vendors to manage the supply capability required to meet the demand. Applications are already PKI enabled, are fairly easy to SAFE enable, in the sense of how they become SAFE compliant, and applications becoming SAFE certified require vendors conform with the SAFE policy framework as specified in the SAFE functional specifications.

So essentially, we have got a network that says, if you would like to be SAFE compliant, you need to be certified or you need to be compliant with this system; here are the specifications and here are some rules to follow.

SAFE and electronic records. Driven by the desire to cut costs, improve patient outcomes and reap the benefits of electronic business processes, SAFE sponsors are investigating the legal, business and technology requirements associated with making use of electronic means in the creation, transmission and long term retention of electronic records. The life of a drug plus five is an example of a long term retention.

Internal differences in the assessments of these requirements may discourage entities from searching for a coherent approach, thus delaying migration to e-records. One difficulty that we are seeing out there is finding the adequate solution that appears to be the different sensitivity levels of electronic records, just like paper records have in practice. Different documents have a different level of sensitivity.

Some e-records represent legal or business assets such as contracts, intellectual property, privacy data, regulatory filings or evidentiary materials. These require a high level of electronic reliability and strength. Electronic prescriptions and related data fall into this category. At the same time, it is obvious that companies particularly in the regulated industry that have failed to establish adequate e-record management systems are exposed to significant litigation, reputation, transactional and compliance risks. SAFE provides the necessary infrastructure and controls to support legal and regulatory requirements for archive and record retention. In no way does the SAFE standard limit how an application chooses to format and structure its electronic records, and regardless of the standard adopted for e-prescribing, SAFE can support the electronic record requirements.

How is SAFE applicable to MMA requirements? SAFE is an open standard that provides NCVHS and HHS with an infrastructure that provides a firm foundation of trust, that establishes a clear means of verifying the identities of those accessing and altering data in the health care community. SAFE is an evolving community that provides NCVHS and HHS with the knowledge and the shared experience of over two years of development across 13 multinational pharmaceutical sponsors. The development and implementation focus specifically on minimizing the integration of end user complexities around visual signatures.

Without exception today, if you consider the business case, all health care participants have established stand-alone proprietary identity assurance systems. The end result has been increased complexity for the end users, without the benefit of being able to electronically sign electronic records.

For practitioners and clinical investigators, this can mean managing as many as five to seven different credentials to access various health care or sponsor information systems. Minimally, the behavior changes required for moving to electronic record and e-prescribing must be simple and cost effective. We understand this more than most would expect.

Our experience to date with SAFE has proven that this is not only possible, but there are compelling value propositions providing the appropriate incentives for change to all stakeholders. The essential ingredients SAFE offers to assist in the deployment efforts is a network effect that can be leveraged for value-added services that practitioners are indeed willing to use.

How long do we continue to develop point solutions that promote isolated and incompatible infrastructures that add complexity and risk to the health care community? We now have the opportunity to establish a shared common identity foundation, and we can all leverage and build from it now, the right way, versus forcing a legacy problem in the future.

It is our assertion that SAFE offers some of the critical building blocks of such a foundation. It is our commitment to work with the NCVHS and HHS to establish that foundation, based on all appropriate standards and stakeholders.

From an overlapping user base perspective, it is widely known that the pharmaceutical industry relies on clinical investigators. SAFE has been initially targeting clinical researchers which represents we believe a significant subset of the overall prescribing community. According to a recent Harris survey, approximately 13 percent of all practicing physicians currently serve as clinical investigators. The Harris survey also goes on to state that over 50 percent of physicians would be interested in clinical research if they could only get access to the information in the network for trials.

SAFE has agreed to fund the provisioning of investigator credentials in 2005. SAFE sponsors are actually providing those credentials in the community now. We are issuing credentials today to investigators, at no cost to the clinical investigators. These same investigators are also physicians responsible for prescribing medicines to patients; additionally they are highly influential in the advancement of medicine.

We believe that the shared cost model established by SAFE provides a governance and business infrastructure that is extensible to meet MMA’s requirements. A SAFE business case analysis performed in 2004 suggests that the industry cost savings just for the pharma space were in excess of $285 million a year, reflecting savings in excess of $100 per user credentialed.

From a conclusion perspective to wrap it up, I have hopefully communicated to you in this testimony that SAFE is not about the pharmaceutical industry, not about pharmaceutical companies or drug development or the FDA or regulatory compliance. SAFE is a platform that can be used to support the broad interests of HHS, to facilitate collaboration among the different stakeholders within the health care community.

SAFE is committed to working with the appropriate standards organizations, with NCVHS and with the oversight of HHS and NCVHS for creating a secure trust platform for e-prescribing and e-health records.

On a personal note, I am the father of a son with acute myelogenous leukemia. I have had the unfortunate opportunity of witnessing first hand the deficiencies and failures associated with our current paper-based health care infrastructure. It was staggering to see the amount of paper involved in the process, and frightening to know that the lack of information transparency, the inefficiencies of a system that force a lack of information transparency, between health care providers actually puts lives of individuals at risk.

It is our belief that the most appropriate solutions for the MMA e-prescribing requirements and HHS e-records requirements for authentication and e-signatures must not distract from the doctor-patient relationship. It has got to be simple. And more importantly, we expect something like SAFE and the solutions that will sit on top of SAFE will enhance those relationships.

Independent of your perception of the relevance of SAFE or whether you think the whole solution works or not, I commend your efforts and commitments to advancing our health care infrastructure. It is my privilege and it is SAFE’s privilege to support the NCVHS in any way we can. We will leave you with the thought that the patient is waiting.

Thank you very much for the opportunity to testify here today. I am ready for questions.

DR. COHN: Thank you very much. I think Stan is raising his hand, and Steve.

DR. HUFF: Several questions. How big is the standard? Is it 200 pages, ten pages?

MR. EVANS: It is 15 documents, on average about 40, 50 pages apiece. Some are less. It is technology specifications, operational. It is leverageable in the context of — can you take pieces of it and use it without getting the whole SAFE standard? No, but I think you can leverage the elements that are in that, if you are looking to evolve something new.

DR. HUFF: How is it distributed, or how can people gain access to it if they are not part of —

MR. EVANS: If they are not part of the network?

DR. HUFF: Not part of the network as defined now.

MR. EVANS: Right, meaning if —

DR. HUFF: Say I was a software vendor, so I am outside of the normal pharma clinical research. I am Turner or Sunquest or IDX and I wanted to implement the strategy within my system, or one of the e-prescribing guys, how would I gain access to the standard?

MR. EVANS: Come of the SAFE website and subscribe to obtain the rules under non-disclosure.

DR. HUFF: Is there a cost associated with accessing the —

MR. EVANS: No, no cost to the sender community.

DR. HUFF: What is the process — you describe it as an open process for progressing the standard. What do you mean by open? There are clear definitions that ANSE has for quote-unquote an open consensus process. I notice you didn’t put consensus process in there, but open, what does that mean in the context of SAFE?

MR. EVANS: We are structured today with primarily pharmaceutical sponsors at the governance level, as well as the FDA, EMEA, EFPIA and PHRMA. I think the message that we are coming to the table with here today is, if there is a requirement to evolve SAFE further, change, enhance or look at the governance model, we are interested in that discussion.

Is there an open process today outside of those board members or those sponsors for others to comment on the rules? You don’t have to be an owner to participate in the process of approving rules changes or edits. You do have to be a member, however.

DR. HUFF: And how broadly is it implemented now? How many people have been given certificates, how many transactions are currently flowing under SAFE?

MR. EVANS: We published version one of the rules in May of this year, meaning we published the version one specification. We are in the process right now of publishing the bridge specifications that insures interoperability between the Johnson & Johnson example and the Pfizer one I gave earlier, or even the federal bridge, for that matter. So sponsor are, I would say, hesitant to deploy production systems until that bridge has been implemented.

Having said that, Pfizer, GlaxoSmithKline and others are in the process of what I would call deploying production operations at SAFE. The National Cancer Institute is issuing credentials, I can’t disclose how many at this point. They are issuing credentials to the users. We expect production operations in the first quarter of 2005, based on the deployment of the bridge.

DR. HUFF: You mentioned the potential cost savings. Have you estimated the cost to implement per user?

MR. EVANS: Not per user. An excellent question.

DR. HUFF: Have you done it on some other basis?

MR. EVANS: We have. We originally looked at the cost of end user credentials as being at approximately $200 per user. We then broke out the business case into a shared cost model, whereby we felt we could be scale alone, meaning all sponsors and purchasers versus one; we could reduce those credential costs to about $135 per user.

We just submitted a request for proposals to issuers, and we found that the savings were in excess of $170 per user, using the SAFE system. I think the challenge with answering this specific question of cost on implementation is, it is different for every entity. That sounds like a loose way to walk away from the question, but big sponsors like Pfizer, 200,000 business partners, 100,000 employees, is a very different implementation than someone like a Genzyme or Genentech or an Amgen, for that matter, or even a practitioner. So it does differ, depending on who you are, and where you stand with your identity implementation as an infrastructure anyway, where it is today.

We do believe though that the cost savings minimally at the user level under the shared environment are in excess of $100 per user.

DR. HUFF: Final question. You point out that the need and level of security on information varies according to circumstances. What is your impression of the circumstances we are looking at here in terms of e-prescribing, and whether — some might claim this is too big a gun to shoot the animal we are looking at here.

MR. EVANS: That is precisely the reaction we were expecting; do we need a howitzer or not. Personally, I think it is a question of risk management. If you need legally enforceable electronic signatures for electronic prescribing, SAFE is a solution that can solve that problem. If you don’t believe you need that kind of solution, and you are willing to accept the risks affiliated with what I would call a soft identity assurance approach, then you wouldn’t need SAFE.

It is hard for me to understand — Paul has a different perspective, and I think he can also answer this question in the context. We were having an interesting debate amongst each other about the reference of the lack of need for e-signature.

MR. DONFRIED: I am the geek, and I tend to come at this from the information security perspective. What I was missing from the testimony that we were hearing earlier, that was all about what I would call design with the performance envelope, which is the way engineers think. This is what i need to do, what is the simplest, cheapest way to get it done.

From the risk management and security perspective, you approach that issue from the opposite perspective. You don’t care how it works. You care how it breaks, and you care when it breaks, how it can be exploited. An analogy, if I am a perpetrator trying to compromise say an electronic prescription system, there are a myriad of attacks that I can introduce to that system that are nonexistent in the paper-based world. The velocity of those attacks in the electronic world is orders of magnitude greater than the potential velocity in the paper world.

Does that answer the risk profile question? No, but I would suggest that the risk profile in general of any electronic system versus a paper-based system is radically different.

As was mentioned by one of the gentlemen testifying, there is also the opportunity from a regulatory perspective and a law enforcement perspective to achieve far greater risk management by bolting analystics engines onto these electronic aggregation systems to automatically flag anomalous behavior or anomalous transactions. That is great in terms of identifying fraud, misconduct and inappropriate behavior. If you are the DEA or anyone who wants to then prosecute that behavior, you need legally enforceable evidence as the basis of your prosecution.

If you have a system that cannot provide non-repudiation, then you are fundamentally flawed and having strong evidence to introduce as part of that prosecution. From a technical perspective, it is fairly well understood that symmetric key systems, which include username, password, secure ID, biometrics, symmetric key systems by design do not support non-repudiation. There is always some other party that has access to that password or that secure ID PIN and rotating number or my thumbprint or my retina. As Bill Gates demonstrated to us in the DOJ antitrust file, when someone holds up an e-mail you reportedly sent, you simply assert that, no, that was an administrator or someone else must have compromised my e-mail account, because I have never seen it.

Public key or asymmetric cryptography has the unique ability to support non-repudiation, assuming your policy framework surrounding the issuance and the protection of that private key is rigorous.

So I connect back to Ashley’s point. I don’t think we know enough about e-prescribing to tell you whether you require legal enforceability, whether you require non-repudiation, whether you require strong evidence that allows behavior to be prosecuted criminally. But if the answer to any of those is yes, then I would assert, you really can’t consider a symmetric use.

DR. STEINDEL: I think you just did a very nice summary of where the line is and what types of decisions need to be made. The question that I have relates a little bit to the last question that Stan asked with regard to the number of users, et cetera.

As I mentioned in my closing comments to the last session, CDC operates a network that is similar to this. It is a very circumscribed community, and it can be done and it can be done well within that circumscribed community. Right now, you are also operating in a circumscribed community, and it can operate very well and very effectively.

But what we heard from the network panel before when we are talking about the e-prescribing world, we are talking in excess of three billion transactions a year, 55,000 pharmacies, 400,000 potential subscribers. When we start expanding this type of system, especially a bridge PKI system, does it scale? And does it scale in terms of de-encryption, et cetera? Can we process that type of information? That is ignoring the question of modifying the transactions which the networks just testified that they needed to do. We have to develop ways to open, de-encrypt at the network level and do things to it so that we can re-encrypt and re-send and still maintain some trusted validity if we went to a totally secure system. Does it scale?

Ashley, you mentioned the size of Pfizer, et cetera. There was some sort of implication that everybody there is going to be issued a certificate under SAFE. That is probably not the case.

MR. EVANS: It is actually not. Let me answer that question. We just finished a project for Pfizer. We are calling it the integrated badge. There are credentials on that badge. In fact, I have one. We are issuing over 100,00 of these cards globally to every Pfizer colleague.

The rationale there is that the alternative is much worse. Imagine I am a consultant and I’ve got to go to New York, can’t get into any of the buildings in New York, and I work in the headquarters in New London. Can’t get into any of the offices elsewhere. That is akin to me not being able to access any of the other systems also. But I have multiple credentials.

The alternative approach was, we were managing multiple systems as an organization, multiple identity assurance approaches, versus giving one credential with multiple applications. So the answer to that question is, we are going in that direction. That is good for Pfizer; it doesn’t necessarily mean it is good for the industry.

DR. STEINDEL: But are these credentials are going to be SAFE credentials, or internal Pfizer?

MR. EVANS: Yes, they are going to be using safe credentials on the badge. The capability is that we provide remote loading functionality. Not every user will have a SAFE credential. The question is, how many users within the system are required to sign legally enforceable and regulatory compliant documents. That is a good percentage. What we have done is provide the capability of remote loading of those credentials onto those cards.

MR. DONFRIED: The short answer is, outside of military applications, NSA, DoD, other governments’ military applications, there are no widespread complex PKI’s.

I personally believe that the fundamental reason for that is not the complexity of the math or the cryptography or the complexity of the integration. It is the fact that we have not made that process transparent enough for human beings. The analogies I would use, SSL is based on public key, and SSL is about as widespread as any secure technology that is used in the Internet, and it is quite transparent.

Nobody thinks it is an issue to go get an SSL certificate for their server and then have peoples’ locks turn on in their browser. IPODs and other MP3 players have as sophisticated cryptographic technology as we are talking about with SAFE embedded in them, and it is 100 percent transparent to the end user.

Our vision for SAFE, our vision for the interaction between human beings and the signing of the validation process is, it has to be that transparent to the physician, to the pharmacist, eventually to the patient. I spent ten years working for Apple Computer, and we had an axiom at Apple that complexity is conserved. Life does not get simpler. It continues to get more complex.

What we tend to do to manage that complexity is to shift it to participants in the food chain who are most capable of dealing with it. So the day that we start talking to 800,000 physicians in the United States about PKI, we have lost. The day we hand them a credential and say, treat this with the same due diligence that you would your credit card or your ATM card, and whenever you need to sign something, stick it in a reader or put it in your USV port, type in a pass phrase and you are done, then I think we win.

So I don’t believe it is your committee’s responsibility to deal with that complexity. I think that is why you bring vendors like you do to the table. I think it is our job as the vendor community to embrace that complexity and insure we don’t push it to the end users.

MR. EVANS: One thing to think about, Steve, in the context of how many credentials and how quickly, I think the question or the concern people may have is how you get the credentials out there.

Industry is issuing millions of credentials, Pfizer 200,000 of them, business partners are doing the same thing, over 250,000 investigators globally. The challenge with that as a community is, we have been issuing totals for access, giving tokens of credentials for remote access versus credentials people really need, which is, how do I sign something electronically. That practice is well known.

DR. COHN: I want to thank you both very much. I think we will all talk tomorrow about next steps about all of this step. As I listened to both of you, I go, you started in May and you don’t have a bridging standard yet, but I want to find out from NCI or FDA what they think. Those are the type of things we will talk about. But I want to thank you for sharing the work that you are doing with the subcommittee. So thanks.

With that, we have Jeanette Thornton from the Office of Management and Budget. You are going to talk about the federal perspectives on e-signatures, so thank you for coming in.

MS. THORNTON: Well, I happened to find out about this last week, so — no fault of anyone’s. I had the pleasure or displeasure of reviewing several regulations concerning signatures or talking about planned regulations. I thought that it would be an excellent opportunity to talk about what the federal government has been doing on a government-wide perspective to address the areas of authentication and signature.

Just to provide a little bit of context, I think everyone has their handouts, and I will try to speak as extemporaneously as possible and not be a slave to my slides. Just some context of where I work, I work in the management side of the Office of Management and Budget. Our office, the Office of IT and E-Government, we have policy and budget responsibility over how agencies invest in IT resources. We also have responsibility over information policy in terms of IT security, enforcing the privacy act and things like that.

My particular area of policy responsibility is in the area of authentication, signature and identification. We have issued guidance on the Government Paperwork Elimination Act, which I’m sure you are familiar with, as well as E-sign.

Over the past three years, at least since the start of the Bush Administration, we have become much more operational in terms of what we are asking agencies to do, and not just prescribe policy, but putting in place specific shared services that agencies can use, based on the build once, use many concept. We don’t want to have agencies have 30 different travel systems; we want to build once and have agencies share those systems. Our views on authentication are very similar in terms of the build once, use many, which I will talk about. That is part of the President’s management agenda and the E-gov portion of that.

Finally, I have the responsibility for reviewing regulations that have a technology component to them. Over the past year, I am beginning to see a lot more regulations that deal with e-signature, namely, one that was just released a couple of weeks ago with EPA, the CROMER regulation, which is a level three or a PKI regulation related to submitting compliance data from the state to the federal government. So those of you who are interested in the regulatory aspects may want to take a look at this EPA regulation called CROMER. If you ask me to tell you what that means, I wouldn’t be able to; something about cross electronic reporting and a couple of other R’s at the end.

So looking at my perspective here, I think the first question — and I am certainly not a technology person as you will see, I am more of a policy, big-picture kind of person — is the signature task. Not one size fits all, all transactions are different, looking at reserving a cam site with the federal government versus some more secure transactions; there is a difference. So I am going to talk about my view of the signature test.

I am going to talk about what our policy framework is, some guidance that we have released to agencies to get some consistency. We have seen that one person at the federal agency can dictate their entire e-signature process, because they are afraid of what could happen if they get sued, so I’ll talk a little bit about that. As well as some operational things that we have been doing to put in place standards based, off the shelf products for agencies to use that we are not customizing, which the government does not do very well, as you may or may not know.

The first question is, is a signature required. I like to ask agencies, right now you can’t if you have a wet signature. Is there somebody in a back room taking out a signature card and comparing it to that signature on that person? Or is it a comfort factor, or what is going on there, and what is required in terms of signature? Are you an open network, or do you want a closed network, what type of controls do you have in place. That is the first question.

I’ll just mention this, does anyone actually verify there is a handwritten signature, and what happens with that? As the previous speaker talked about non-repudiation and looking at what level of non-repudiation is required, whether you are dealing with someone polluting your groundwater and someone going to jail for putting bad things in water, versus reserving a cam site. There is obviously a level of difference there.

Finally, one of the questions we have in the federal government, and I’m sure it is very similar to your industry in terms of what are the recordkeeping requirements and how that information is going to be accessed. I am by no means an expert, but I know that this has been giving federal agencies a problem for a long time, in terms of how do we deal with electronic records, especially with technology constantly changing. I will provide you with no answers there.

EPA did try to go out with a draft of an electronic recordkeeping regulation. They got so many comments, they decided not to issue it. So they said, figure it out on your own, industry, which is not very comforting to me, but it is what it is.

Signature frameworks. We have told agencies that one size does not fit all. From a privacy perspective and a security perspective, there are different things that need to be balanced. I think it is important at least for an industry security person, they are always going to want to jump to the highest level of security possible, because of that fear. However, from a privacy perspective and a person not wanting to give up so much of their privacy, our guidance to agencies tends to go to the lowest level that you can sustain with the controls that you have in place for your system.

We have broken out the universe into four levels of authentication and signature requirements. Just so you get a sense of where I am, I think it is page six. We developed guidance, and we issued it last December, so we are about to approach the one-year anniversary. This is guidance for federal agencies only, but we have seen plans to be adopted by about 12 or so states, as well as a partnership of industry, which I will talk about. So it is getting traction, although I admit that it is not perfect. But I think it is a good starting place to try to get some consistency, at least how we are going to get our hands around the authentication and signature issue.

We have broken the world into these four levels, based on the risk of an authentication error. What happens if someone’s information goes to the wrong person, or someone uses that information to do harm, and what would be the risk. The risk of someone getting your credit card number and having the protections in place that the credit card industry has are a little bit different than somebody — the polluting water example, or the risk of somebody getting Oxycotin or something. There is a little bit different of an approach there.

So we put in place a policy framework that agencies can use to determine, looking at a specific transaction, what is the risk. Risk is subjective, I understand that risk can be very subjective, but I think it is important to have some level of consistency.

To couple that, we asked NIST, who is the government standards making body, to provide companion technical guidance that talks about what are the technology controls and what standards need to be in place to mitigate each one of those levels of risk. So you will see a sliding scale. The guidance talks about what you need to do to identity proof, what you need to do to — what sort of security controls needs to be on the system, the entropy, if you are using a PIN and password, what level of entropy is required, and many other things. So I think for all of you to take a look at that document would be very helpful to get an idea of what we are prescribing for federal agencies who are doing authentication.

The guidance puts forth five steps that agencies need to go through in order to determine their authentication assurance level. We are asking agencies to submit the results of those assessments next week, December 15. So we will get a sense of where things are and how things really work with this assessment.

We are seeing that most federal agency transactions fall out at about that level two, level three threshold. A lot of them in the PIN password area, and some requiring some form of digital certificate.

How we know that is, the guidance has a chart of potential impact, and agencies are asked to look at six categories of harm or potential things that could happen if information was given to the wrong person. Anything from a minor inconvenience to financial loss to a bad public relations scare, unauthorized release, safety in the example of a controlled substance that I mentioned, or similar criminal violations.

I think it is not just a plug and play sort of thing. You know risk assessments can be very complicated, but it is a starting place.

Next we have mappings of each one of these levels, the specific technology. On slide nine you will see some examples of how we categorize different technologies to meet the levels. We are starting with the risk and the policy, then moving to technology. We are not picking a technology and working backwards. Some agencies would like to do that, because sometimes that is the easiest way to do it, but our approach is to focus on the risk first and then pick the technology that mitigates the risk.

It is important to note that some agency transactions may fall in at a higher level, but there are some compensating controls in place that allow you to use authentication that is at a lower level. That is done on a case by case basis, but it does happen.

What does this mean in reality? I’ll talk a little bit about the policy framework. We have made this framework operational in what is called the e-authentication initiative. I’m not sure if any of you have heard of it or really know what it is. We are basically creating government-wide single sign-on, using both technology or a standard called SAML, or federated identity management, and using level three or four or PKI.

The concept is that a credential from one agency or a private sector source can be used for multiple agency application. That is why this risk assessment is so important. We have to know what risk assessment level each application is at, and we have to also know what level each credential falls at.

So let’s put this in a personal example. I have a Bank of America user ID and password that has been certified through a rigorous audit process as being a level two. I can now use — and I will talk about some of the pilots that we are doing — use that Bank of America password for any federal agency application, this is the goal, that is a level two or lower. That Bank of America pass has been certified. If I have a level three authentication mechanism, a certificate, I can use that level three certificate, whether it is issued by an agency like DoD, or whether it is issued by a bank or in your ISP or pharmaceutical industry, can use that for any level one, two or three authentication mechanism. The initiative is putting in place the standards, the policy and the architecture to make that happen.

For levels one and two, we are using SAML 1.0 right now, but plan to be moving to SAML 2.0 in the future, and we have an interoperability lab in place to test SAML products. We have 13 standard products that are proven interoperability. What that means is, if you get a password from one vendor’s product, it can be accepted by products across the board. It is an e-concept. It does show that the government doesn’t have to withhold into a proprietary approach for authentication.

Approved credential providers. Everyone who is issuing credentials in this federated network, where credentials from one source can be used for another source, we have to trust them. So we have a policy framework in place called a credential assessment framework, where a government team goes out and audits your facilities and determines what level you are given. Once you have been granted a level, you are given a certificate to put on your server, that we know that you are trusted.

Interface specifications are also a key part of our architecture. We do not have any single point. This is completely federated; transactions are going back and forth between applications accepting them and credential providers. So we have to have a standard way of communicating. We have chosen to use SAML. We also have a piece in place that will convert a digital certificate to a SAML assertion. I think you guys probably understand what I am saying hopefully. If not, we will talk about it when you have questions.

There is also a portal in place, so a user can find all the different applications that are available across the federal government and click on them and see which credentials they may already have in their wallet that they can use to access those applications.

We are engaged with the financial services technology consortium, and have over 40 financial institutions, many of them that you are probably familiar with, participating in a proof of concept, where we are testing this concept with the financial industry to test the business model of accepting financial credentials for government applications. So we don’t have to issue them ourselves. We also have 13 other agency pilots underway right now.

Just to give you a concept of one of them, if you are familiar with the grants.gov website, where it is a standard place in the federal government where you can find and apply for grant applications, if you have a credential from the National Science Foundation system, you will be able to use that credential to apply for your grant and not get a separate credential from the grants.gov system. You will also be able to use credentials once it is fully operational from any number of other credential providers.

So that is e-authentication in the quickest nutshell that I can possibly give it.

We have taken this concept, and we went out to industry and said, we are doing a federated architecture for the government’s transactions, do you think that this would work across industries, between the mortgage industry and the drug industry and the financial industry, so if you are applying for a mortgage and have to get it signed across multiple domains, how could that really happen.

We have related it to the concept of the credit card industry, how it was when it was first getting started. Their focus was on business rules, and in order to be able to trust VISA or Mastercard you had to have sound rules that people had to comply to.

So this electronic authentication partnership is about a year ago, and it has been focused on putting in place the business rules for — I like to call it cross entity authentication, portable authentication across multiple domains. They are going to be formally kicking off with their board and their governance structure at the beginning of the year.

Just to note, they have adopted OMB’s levels of authentication as their similar levels for this group, so they are going to have a similar concept for their authentication and signature.

Just briefly, because this came up in a conversation I had with HHS staff last week, I know that there was some interest in work with smart cards and biometrics, so I wanted to talk a little bit about that. This is only as it applies to federal employees and contractors; it is not as it applies to Joe Public on the street.

We have a Presidential directive that we are required to meet, that I am leading implementation of for agencies, which requires a common interoperable credential in the hands of every federal employee and contractor to be used for physical and logical access by October. Never mind, that is what the President said, so that is what we are going to do.

We have been dabbling in — federal agencies have been dabbling in the smart card community for awhile now. We have seen successes at the DoD and other large agencies, but it hasn’t really been a ubiquitous, interoperable credential. So we are working towards that. We are publishing our final standard in February. It is going to have some biometrics implication, it is going to have some smart card industry implications, et cetera. So I can get you some more information on that if you have questions. I just knew that some of you may be interested in that.

I’m done. Thank you for letting me come and speak about what we are doing on the federal agency perspective. I hope that you will be able to find what we are doing valuable. At least you should know that you are not starting from scratch. I think we have produced a lot of things that you all could take advantage of for your particular industry that you are working with. So, thank you.

DR. COHN: Thank you very much. This is fascinating. I feel like we should have had you at 8 o’clock this morning rather than this afternoon.

MS. THORNTON: I was in bed at 8 o’clock this morning.

DR. FITZMAURICE: You have heard throughout the day some of the demands that have been made on electronic prescribing and its use of electronic signatures. Somebody could get access to narcotics, somebody might get access to the wrong drug, so there is an integrity concern, there is an authentication concern. There is also a business concern, that it will take up so much costs. There is so much difference among the different solutions that implementing them would bring some kind of chaos and slow things down, so that electronic transactions wouldn’t grow.

But as I look in the government, I am trying to look for something comparable, something that involves the same kinds of risks, risk to personal safety, risk to information that might be embarrassing or harm somebody, maybe in the Department of Defense. But let me ask you that question. Can you think of any example in the government, and I apologize if I put you on the spot, I don’t want to put you on the spot, that involves some threat to patient safety, where an electronic signature solution is used, something that we could look at to see how it works, and how it might scale up to a large use.

MS. THORNTON: Recently I have had a lot of conversations with the Veterans Administration. Right now when you apply for veteran’s benefit, you fill out a form and you can submit it electronically, but then you have to mail in a separate signature card. They are looking to take advantage of e-authentication to solve that problem. It is not the same level of what you are talking about though, in terms of transferring a record.

Let me keep thinking here. I know that the Environmental Protection Agency has been involved in these sort of efforts for awhile now. In their system it is called CDX, or Central Data Exchange. They are receiving compliance information both from actual industry companies electronically with signatures, as well as, they will be receiving under these new regulations compliance data from states. So that information can be proprietary and can be very sensitive. So I think that is one to check out.

DR. FITZMAURICE: Tricare online?

MS. THORNTON: That is DoD, right?

DR. FITZMAURICE: Right.

MS. THORNTON: Yes, that is another one. DoD, with their common credential they are focused on physical access to facilities thus far, and they are just beginning to ramp up their use of the signature capability. I know that they have implemented it for many individuals.

Tricare, I’m not sure of that particular application, but I do know that in the procurement industry within DoD, which has a lot of sensitive information that is being signed, electronic signatures issued by a DoD certificate authority.

I didn’t mention that what we are doing in terms of the federal government is, the federal bridge architecture is a part of that for higher levels of transaction. I didn’t talk about that, but that is a whole other presentation if anyone is interested.

Let me think about — in terms of widespread just signing of forms, one of the biggest success stories in the federal government is the student financial aid application. That is a lower risk application, because a students is verified once they show up at a school. That is an example of where controls mitigate the risk factor. You sign your financial aid application, contending that you have certain income requirements, certain income needs, but you don’t actually get the money until you show up at school somewhere and someone looks at you and looks at some identification, et cetera. So that would be an example of a high dollar signature, but it has a lot of controls in place to prevent — not saying there isn’t fraud, but a lot of controls in place to prevent fraud, even though they use a lower risk signature device. Right now, it is a five-digit PIN. So that is a good example.

I could go on. PTO is another, Patent and Trademark Office. It has had a lot of success in reviewing sensitive patent information and signing, patent applications.

MR. REYNOLDS: On slide nine, where it talks about the hard crypto token and the soft, is there any way to get definitions? You wrote zero knowledge password, what all —

MS. THORNTON: Zero knowledge password is actually a RFA smart ID card. The NIST guidance goes through an excruciatingly painful detail on what each one of these are. Hard crypto token is a smart card. Soft crypto token is a digital cert. Zero knowledge password is an RFA smart ID. One time password is a temporary password. I don’t know what else to say about that one. Strong password has a certain entropy. A PIN is only four or five digits, and strong password has a combination of numbers and characters. I would refer you to the NIST guidance for that.

DR. COHN: Jeanette, I just wanted to ask you a couple of questions here. I am just asking for your help in terms of thinking through some of all of this.

I think you may have begun to answer some of my questions. I am looking at the framework you are presenting, and I am trying to crosswalk that versus mitigating factors. I walked in here feeling that for the business case that we are describing, and we are talking about e-prescribing and the provider somehow getting that information off, and what sort of authentication does that person need.

I am wondering in terms of mitigation pieces, because as I look at this one, I was thinking maybe they need smart cards, as I look at your framework. But do things from your perspective, like leased lines or virtual private networks, is that a type of mitigation — is that one of the mitigating things that you were talking about, versus just sending something out on the wild Internet without that? Is that the type of mitigation that we should be considering?

MS. THORNTON: Before I answer the question, as we know, Power Point is leading to the stupification of America; you have to look at the corresponding guidance behind these. A lot of detail, especially on the potential impacts that go into that, just so you know, it is not a one size, slap it in, slap it out sort of assessment.

But yes, it has to be viewed — and this is where it gets complicated, it has to be viewed as part of your overall risk management approach, as part of what controls you have in place. So there are a number of compensating controls that we talk about in the guidance that can be used to mitigate risks that would lead to your lowering the mitigation assurance level. Anything from different network configurations, different business process things that occur, that verify down the road that you don’t necessarily verify up front, but things happen down the road that coupled with that transaction would lead to a greater assurance that you know who you are dealing with.

For example, a common example is when you apply for a benefit, you are signing that benefit application form. That doesn’t automatically mean you are going to get a ton of benefits. There are lots of other checks and balances that occur in the process that happen before you actually get your benefit check. So those kind of checks would be viewed as compensating controls. If it was a situation where you submit the information and something automatically happens without such controls, you would have to look at it in a little bit more detail.

But risk is so subjective, too. I have learned that more and more, that one person’s view of risk is different than another person’s view of risk.

We put out this guidance because we had inspector generals or office of general counsels who were saying, we just can’t go beyond paper, it is too risky. So we went out with this guidance and said, we need to start putting some consistency on how we are doing this across the government.

DR. COHN: We have talked about authentication, but there is also the piece of tampering along the way. I guess those are separate pieces, as i would imagine. Maybe it is in the documentation or whatever.

The other question, and I apologize, I assume you have been here for the last little bit.

MS. THORNTON: No.

DR. COHN: Did you hear about the SAFE presentation?

MS. THORNTON: I am familiar with the SAFE program.

DR. COHN: Okay. I found myself listening to them, hearing that the FDA is involved, hearing your work, trying to figure out how all of this either fits together or doesn’t fit together, how your NCI is going to be using this in one of their systems. Can you explain how all of this works?

MS. THORNTON: Big government.

DR. COHN: I hope I’m not embarrassing you.

MS. THORNTON: This is very interesting, because this is a problem that everyone is trying to solve. A couple of years ago what we were seeing was each individual agency trying to solve the problem. Now we are seeing these federations popping up across government-industry that are trying to solve the problem for a particular domain.

So we have SAFE looking at this problem from the pharmaceutical industry, e-authentication looking at it from federal e-gov type of applications. There are some overlaps, but they are similar, in that you are seeing pulling together of federations of different industries or different groups.

One of the things that this partnership that I talked about is trying to do, and the judgment is still out, is taking all of these federations and these partnerships and bringing them together so they are interoperable. In an ideal world, a safe credential, if they were cross certified with the federal bridge, their program would be accepted at an agency application. That is the concept. As credentials become more and more affordable, these infrastructure structures get put in place.

We have been working mainly with the HHS CIO office. I know that HHS is a large distributed place, so whether or not the — and also with National Institutes of Health and the university community in terms of using credentials that university students have for access to federal applications. It is a technology called Shibboleth. We have been working with that. So sure, there may be different groups going on, but hopefully over time they are going to converge as standards converge.

DR. COHN: Thank you. I have a feeling that this bridging would have —

MS. THORNTON: I would rather worry about bridging major industries than bridging little bureaus or little stovepipes, if you will, you know what I mean? I think it makes sense to look at authentication from a broader perspective.

What we had before was agency applications looking at authentication just from the perspective of their unique application, applying for student aid and applying a solution to mitigate that solution. Now we are looking at it more broadly, in terms of what credential would a college student have for many different purposes, not just one.

DR. COHN: Maybe I will ask one additional question. This is one we were all mulling over. Do you feel there is any increased risk if we have single sign-on for all of this?

MS. THORNTON: There sure is. The more risk gets placed, the more strong the credential has to be. It is by choice. It is all opt in. So if someone wants to have 40 different credentials like you do now, that is not a problem.

We think that people will move down to fewer credentials, whether they will always be at one credential — I wouldn’t personally want to use the same credential that I use as a federal employee for my personal business. I certainly wouldn’t be comfortable with that just from a privacy perspective. I’m sure I am not alone in that assumption.

DR. COHN: Other questions, comments? Thank you very much, it has been very useful. I think we do have to look at — I’m almost afraid to look at how many pages some of these — only 65 pages?

MS. THORNTON: Well worth reading.

DR. COHN: I should ask, is that federal print or is that regular print?

MS. THORNTON: Actually in Times New Roman size 12.

DR. COHN: That is not too bad. We will try to take a look at it. Thank you. I think it is a very timely conversation, so we really appreciate it.

MS. THORNTON: Thank you.

DR. COHN: With that, we will move into the open mike and see if there is anybody who wants to make any statements, has any comments from today’s activities so far.

I guess I should then ask the subcommittee if you want to express any thoughts about what you have heard so far, any epiphanies, ah-ha’s, things we need to be careful to note, while it is still fresh.

DR. HUFF: What I did was not make any decisions about anything, but listening to these folks, what I did do is make a list of what the requirements are for whatever we chose. I don’t know if you are interested in that. I came up with 11 points.

DR. COHN: Please.

DR. HUFF: I’ll go through them quickly. The first one is, improve the safety, cost efficiency and confidentiality of medication prescription and use. We accept the definition of electronic signature as specified in E-sign 2000. We are striving for interoperability, so that there would be a national standard or set of national standards. That might be controversial, I don’t know. But I am assuming that we want to be technology vendor neutral so that we can allow for open fair competition to drive down costs and improve functionality.

We don’t want to invalidate current appropriate law, business policies or practices and procedures for validating the current process. There should be an ability to audit or trace an individual transaction. Have e-sig for e-prescribing be consistent with e-signature in the rest of the medical transactions and data interchange, especially with HIPAA transactions and other EMR activities.

I heard this, this one might not be universal, but use the same e-sig process for schedule and non-schedule drugs. Allow for translation of transactions between different versions of the standards. Easy and inexpensive to implement, so as not to be a barrier to adoption. We are back to motherhood and apple pie stuff.

DR. COHN: That sounds good, though. It may be a little bit hard to achieve, but —

DR. HUFF: And the last one that I had was, allow for evolution, so that there is a way for new versions of the standards or innovative approaches to be prototyped, which is an issue we have encountered before.

MS. FRIEDMAN: I have two questions for Stan. One is, on that one bullet about interoperability with HIPAA and all of that, if we don’t have HIPAA standards for this, I’m kind of confused; maybe my brain is soft by the end of the day. Would you repeat that bullet?

DR. HUFF: Yes, I will repeat it, and then I will tell you what I thought I meant.

MS. FRIEDMAN: Okay, and then I have one more followup.

DR. HUFF: I said we want to use the same e-sig for e-prescribing that would be consistent with the rest of the medical transactions and data interchange, especially with HIPAA transactions.

In other words, if there are any HIPAA transactions like attachments that need to be signed, we want what we do for e-prescribing to be consistent with e-electronic that is used for that other purpose.

MS. FRIEDMAN: That is really great, but aren’t we out in front with the rest of that?

DR. HUFF: I’m not saying we can do any of these things. If we were omnipotent, that is the way we would have it, wouldn’t it?

MS. FRIEDMAN: If we come up with standards for e-prescribing, aren’t we coming out in front of standards for some of those other things that are in that bullet, like electronic medical records and stuff like that? In fact, we are really setting the threshold.

That relates to the follow-on question about the same standard for controlled and non-controlled substances. If the DEA comes out with their reg and we go by that, then that becomes the standard for everything, presuming for example that they come out with whatever they come out with.

We have heard that people don’t — there are a lot of costs and other things associated with having two sets of systems. In an ideal world you would have one system for both. But do we really want to go with that? I don’t know. That is just a question.

DR. COHN: Stan is I think reflecting some of the things we heard in the testimony. Harry has a comment. Is this a follow-on?

MR. BLAIR: Yes, it is related to Stan’s list. Thank you, Stan. You captured at least the things that we could agree that we heard. I think that is good to build on. I think it is going to be interesting to see in our testimony tomorrow what either gets added to it or refined from it.

As I listened to your list, the one thing that struck me -remember, I said I tended to go by stereotypes and then I find that they are wrong? One of the characteristics that I had assumed we would have to include in electronic signatures was non-repudiation. From the testimony we heard today, I’m not sure that that is a requirement anymore. Tomorrow we may hear that it is.

But I think it is interesting. If that does not turn out to be a requirement, then that gives us some additional flexibility in terms of what solution we may recommend.

Then of course, the other thing, Maria mentioned it, is if the DEA has some requirements which are just simply unavoidable, then what do we do. We may be in a situation where we have to decide whether there are two separate standards that we put forth, one for controlled substances and one for not, or do we wind up saying that that is too costly and we just have to go with one.

So anyway, those are the reactions that I had to your list, which I thought was very helpful.

DR. COHN: Harry.

MR. REYNOLDS: I didn’t hear anything in Stan’s list that gives me grief. But what struck me today is, we started off, and Kepa gave us a framework, and then we heard from the people that we have been working with on e-prescribing, and we all seem to be moving along together in some kind of a — you weren’t hearing anything that was making you think differently.

All of a sudden, SAFE came. It was like they are standing on another hill. That is not in any way derogatory or positive. They are standing on another hill. So we are all going this way, and then they are standing on another hill with a different perspective and a different process.

Then when OMB just finished, I thought she did an excellent job, when you take the categories of level one, two, three and four, and then you take some of the other things that they have identified that the government has said, this is your confidence level as to what is going on, you approach that in a couple of ways. You can just put in one measure, or you can put in a layered — that lets you go from level two to level three.

When it says on level three, high confidence in who the person is, and you start thinking of e-prescribing, it makes me start thinking, where do we want to fit? Do we want to fit in one, two, three, four? I’m not saying that is your ultimate outcome, but you have got the government that has put out a structure, and they have put out a definition. So I would assume, if I were re-evaluating what we said, I may say, you came out, and there is limited confidence that prescribed this is who you are talking about.

We heard today about, they hook into a system ID and they hook into this. So as we go through tomorrow and we go through our deliberations, SAFE just jumped out. I’m still not sure what to do with that in my mind. Then the government is giving us a different structure to look at. So I think by noon, I thought maybe we were heading in a direction; now I’m not sure what I think.

I think Stan’s list is a good thing to bounce some of this off of, too. So I think the journey looks a little different than it did when we broke for lunch.

DR. COHN: Harry, if this were easy, we wouldn’t have had you on the committee.

I do want to make a comment while our speaker is coming up to comment. The one thing I would add to all of this is that we need to be aware that there may be a role in pilots. So we just need to be aware of that, that if there are questions or otherwise, we do have the capability to recommend pilot testing of things. So just keep that in mind.

Please introduce yourself.

MR. SHEETH: My name is Tony Sheeth. I have spoken to the committee before. I am managing partner of Point of Care Partners, an e-health consulting concern. I have been involved in electronic prescribing for ten years. The other thing I have explained in the past is how I represent a number of different stakeholders, including the clinical software companies.

I thought Stan had a great list, but the one thing that I think was talked about today that wasn’t on his list that I would like to — if I can put in a vote, if I have a vote, I would just like to underscore, and that is the issue of pre-emption. I have talked about this before. In the last ten years that I have been involved with electronic prescribing, I believe that state board of pharmacy rules and regulations have been one of the top two or three barriers to the adoption of electronic prescribing over the years.

It is getting better. Eleni talked about the fact that it is getting better. But I thought that Geff, the attorney that spoke this morning, made a really good point about several things relative to that, as did Mary.

I would like to underscore from the physician office software standpoint the costs associated with dealing with boards of pharmacy. I personally have testified to boards of pharmacy. There is a cost to go into that testimony, preparing for that testimony and travel and things like that. I have retained attorneys before. There is a cost to an organization of having an attorney put together a survey of boards of pharmacy. There is a cost to that. There is a cost of keeping on top of that, to making sure that when something changes, that they are aware of that. There are costs associated with polling, because some of the rules and regulations aren’t clearly specified, exactly what their position is on electronic prescribing, so there are costs of polling.

There are a number of costs to these software companies associated with this. As I have also testified in the past, revenues at the moment are not particularly high. We believe most of the models, revenues associated with number of transactions, we believe that revenues will increase over time, but right now, the costs of dealing with the fact that there are separate state boards of pharmacy that have different rules and regulations are substantial compared to the revenues. That proportion will be going down, but it is something that I would urge you to keep in the back of your minds.

I represent four different software companies, a number of different stakeholders. Tomorrow you will have clinical software companies that will be up here testifying. I would encourage you to ask them about that after the fact. They are going to be here to talk about electronic signature, but I encourage you to ask them about that. I can’t emphasize enough how important I believe that this issue is.

One last comment, and I’ll leave. I was strongly encouraged by Mr. Catizone saying that they weren’t against that, as long as we do it right at the federal level.

So that is my comment.

DR. HUFF: It was in there. I didn’t use the pre-emption word, but that was the intent when I said we require interoperability and a single national standard. That was my way of saying that exact same thought.

MR. SHEETH: Fair enough. Thank you very much.

DR. COHN: Other comments from everyone? Steve.

DR. STEINDEL: Simon, there has been a lot of good though today, and a lot of good things that have come out. I think one of the questions is, how much risk are we willing to take in the e-prescribing system. I don’t know if we can really decide that as a committee.

There was one comment that was made, I think it was Richard Brook that actually made the comment, but I’m not sure, but I think it was during that session, where they were talking about somebody, a pharmacy receiving an electronic prescription, printing it out, faxing it back to the prescriber so they could get it signed and coming back. I leaned over to Jeff and I said yes, and the clerk signs it.

This is really a realistic situation. How much authentication do we have in the system today, how much do we want to change it, and what levels of risk are we —

DR. GREENBERG: First of all, I congratulate those who organized the testimony today, and those who provided it, because it was outstanding.

DR. COHN: Such as Maria.

DR. GREENBERG: And I thank everybody for that. I think that is what it comes down to a lot, is risk, as Harry was saying. I think the testimony from OMB was excellent. I am really pleased that we are on their radar screen, so that was good, or that they put us on their radar screen.

But it may not be the committee’s role to even answer that question. It is probably a major policy question, and it probably is the role of the Department ultimately in issuing regulations, but certainly the committee can be extremely helpful to the Department in laying out all of the different aspects of this. If these are the types of risks and this is the level of risk that you are averse to, you need this, but if you can accept something else, you need something else.

So I think that I’m not sure first of all, it may be very difficult for you all to agree, and then for the full committee as well, on something this — not complicated, because we have certainly dealt with complicated issues, but it really is a policy issue at the end of the day, related to costs and benefits as well. But I think that this testimony and others which you will hear in the next few days will really allow you to help the Department make that kind of call.

MS. FRIEDMAN: Just to follow on what Marjorie said, even if we don’t come up with recommendations for specific standards, I think Marjorie’s point is well taken, in that if we include some of the discussion and things that need to be considered when the Department does go forward with things, it will be very helpful.

Ideally we would come up with standards, but even if we don’t, having this will be very helpful.

DR. STEINDEL: Picking up on what Marjorie was just saying and Stan’s list, he had two items in there that really are policy decisions that are going to be made at the Department level. One is one standard for e-prescribing. DEA is part of HHS. DOJ, I’m sorry. They are going to be separate, but we can still make the recommendation, and it can be adjudicated at the OMB level.

If that is something we decide to make, we can make that recommendation.

The other one is of course with regard to HIPAA standards. As Maria pointed out, what is coming first, then e-prescribing may come first. This may set precedent for the other standards. That is a Department level policy decision.

MS. FRIEDMAN: It has implications also for security stuff in general.

DR. STEINDEL: Yes, in general.

MR. SHEETH: Just a question. The DEA, do they do NPRMs just like HHS?

MS. FRIEDMAN: Yes.

DR. FITZMAURICE: In reviewing the testimony, I thought a lot of the testimony was just outstanding. When I got down to the end and asked Jeanette, do we have anything in the government that is like e-prescribing, the same level of concern over patient safety, we probably do somewhere, but it doesn’t come to the top of any of our minds. So it is hard to find an example of something like e-prescribing.

I think this puts a lot of pressure on the pilot testings that are supposed to begin next January, that is, a year from this coming January, and some pressure on us to give suggestions to the Secretary about what should be in the pilot test, and maybe how to test them.

For example, I would want tested, does it slow down the system to have different kinds of encryption or electronic signatures? When you hear of them talking about lots of transactions flying per second, that becomes a real business concern.

Then we should also be concerned with the frequency — and I guess you would have to look at the real world for this, how frequently does a prescription get intercepted somewhere and changed, and maybe somebody’s drug habit builds up, or maybe somebody sells drugs on the basis of e-prescribing. It is probably so small now that there is not a large volume of e-prescribing that you could test that against, but it is hard right now for us to weigh the burden and the benefit of electronic signatures.

So I suggest that we frame some things in terms of guidance for the pilot.

MS. FRIEDMAN: Just to comment real quick on the fraud and abuse aspect, it costs Medicaid a lot of money every year when Medicaid mails out fraudulent prescriptions. Medicaid is just one of a number of people out there for whom altered prescriptions in any form, either the content or the prescriber or the patient, it is big business, big bucks.

MR. BLAIR: Does that wind up saying non-repudiation is important? Maybe so.

DR. FITZMAURICE: I think it is going to be important when we hear from the providers. Somebody is going to say, doc, you did this, no, I didn’t do this, and the pharmacist says, yes, doc, you did, I can non-repudiate what you did.

MR. REYNOLDS: Wouldn’t want the VA is doing from an automation standpoint with their medical record and all the automation they are doing have to face —

DR. COHN: Sure, and DoD.

MR. REYNOLDS: That would be one that comes to my mind.

MS. FRIEDMAN: We have asked VA to testify. They may be able to come in January.

MR. REYNOLDS: That would be one that would be closely in proximity, because they have got doctors, not just in the facility. So we have got a lot of data flowing back and forth there, and of levels of approval.

DR. COHN: Please introduce yourself.

MR. HAAS: I’m Jim Haas, I am with Web MD. A couple of points that I wanted to make. One may come up a little more tomorrow, but we have talked a lot today about the technology side of e-prescribing from the point that the message is created and transmitted to the point that it arrives somewhere else. I think it is important to keep in mind that there is stuff that happens before it is ever put into a system, and things that happen when it comes out.

One of the things that we want to do as we assess the risk is to say how high is the risk between the user interface, before the information is put in, compared to the risk that occurs during the message in transition, and then the risk that happens when it pops out the other end and somebody is going to do something with it.

So I think that — and I guess what prompted me to say this was the comment about the Medicaid fraud, and being in the business of routing transactions. I felt that I had to come up and mention that I don’t think anybody has ever prosecuted a switch and put it in jail for altering the transactions. That seems to happen before they are put in or after they come out.

So I think we must keep in mind where the risks are and where the risks should be controlled, as far as risks are introduced into the process, and that transmission piece is not where the risks are introduced.

The other question that I wanted to make is, remember that we do have a history. I wasn’t here or Richard’s presentation, but I know that there have been millions of transactions, prescriptions, that have already been transmitted electronically, and there may be some value in some retrospective studies saying, this has already been happening, is there anything we can learn about fraud and abuse or problems in areas where this has taken place, has this introduced more or less problems.

I think a pilot study would probably generate less transactions to look at than the real transactions that have taken place over the last eight years.

MS. FRIEDMAN: But that would argue for an evaluation of the testing —

MR. HAAS: But I am saying it is a resource that is available.

DR. STEINDEL: Just a couple of comments in picking up on what Harry was saying. First of all, I think mostly Jeanette really didn’t have examples on the tip of her finger. I think there are a set within the federal sector that we can point to. Tricare Online is one of the more simpler cases where they are doing a lot of authentication and accessing military and medical records from the Internet. Then of course there is a lot of internal stuff like in the VA, et cetera.

With regards to the comment on fraud and abuse, one of the first sets of testimony we heard way back when, if we can remember, was from the Florida Medicaid system, where they showed that they cut fraud and abuse to the point in e-prescribing where the governor decided to roll it out all over the state quicker than they expected.

DR. COHN: I think maybe we have had enough of the conversation. We are going to start at 8:30 tomorrow morning, and we will be adjourned for tonight. Thank you.

(Whereupon, the meeting recessed at 5:33 p.m., to reconvene Thursday, December 9, 2004 at 8:30 a.m.)