[This Transcript is Unedited]
Hubert Humphrey Building
200 Independence Avenue, SW
Washington, D.C.
Discussion - Subcommittee
DR. COHN: Would everybody be seated, please? Good morning. I want to call the meeting to order. I'm Simon Cohn. I'm Chair of the Subcommittee on Standards and Security for the National Committee on Vital and Health Statistics. I want to welcome the subcommittee members and the members of the National Committee and HHS staff and others that are here in person.
I also want to welcome those listening in on the Internet. I want to remind everyone here -- I'll be reminding you all from time to time throughout the day -- as we make comments and ask questions, we need to make sure we speak clearly and into the microphone, so people on the Internet can hear.
Now, the focus of the hearing over the next two days is HIPAA administrative simplification and electronic signature. The role of the NCVHS and HIPAA in electronic signature is twofold. One is that in complying with HIPAA administrative simplification, the Secretary is to rely on the recommendations of the NCVHS. Obviously, that is primarily what we are talking about today in relationship to the electronic signature. The NCVHS though has also been asked to track implementation for both HHS and Congress, and identify implementation issues and barriers, and recommend ways to mitigate those issues.
The overall purpose of the administrative simplification of HIPAA is to improve the efficiency and effectiveness of the health care system by establishing standards and requirements for the electronic transmission of certain health information.
Section 273 Subsection E of this particular subtitle is entitled electronic signature. I had to look in there to figure out what subtitle this was. It calls for the Secretary of HHS in conjunction with the Secretary of Commerce to adopt standards specifying procedures for the electronic transmission and authentication of signatures required in future HIPAA transactions.
As most of you are all well aware, there are currently no plans to specify electronic signature standards in any of the immediately upcoming final rules. Thus, the subcommittee and the NCVHS felt it was timely to hold hearings to visit the issues and opportunities of electronic and digital signatures for health care.
As we start these hearings, I first of all want to thank both Kepa Zubeldia and Stan Akmunson for their leadership and work in terms of putting this together. I appreciate your work on this. We obviously thank those of you who have come to participate. This testimony will obviously help the NCVHS develop recommendations to the Secretary.
With this rather long introduction, let me start with introductions around the table and then around the room. Karen, would you like to start?
MS. TRUDEL: Karen Trudel from the Health Care Financing Administration, staff to the subcommittee.
DR. ZUBELDIA: Kepa Zubeldia with Claredi, a member of the subcommittee.
DR. GELLMAN: I'm Bob Gellman. I'm a privacy and information policy consultant from Washington and a member of the committee.
MS. BEBEE: Suzie Bebee. I'm with the National Center for Health Statistics and staff to the subcommittee.
MS. BALL: Judy Ball. I'm with the Substance Abuse and Mental Health Services Administration and staff to the subcommittee.
MR. BEATSON: This is Rod Beatson from Cybersign. Sorry I missed the loop here. I thought it was maybe somebody over there.
MR. BARNETT: Dave Barnett. I'm a security architect with Kaiser Permanente.
DR. FITZMAURICE: Michael Fitzmaurice, Agency for Health Care Research and Quality, government liaison to the National Committee, staff to the subcommittee.
DR. BRAITHWAITE: Bill Braithwaite from HHS and staff to the subcommittee.
DR. FRAWLEY: Kathleen Frawley, St. Mary's Hospital, Passaic, New Jersey, member of the subcommittee.
DR. BLAIR: Jeff Blair, Vice President of the Medical Records Institute, Vice Chair of the Subcommittee on Standards and Security.
DR. ADLER: Jackie Adler, National Center for Health Statistics.
DR. COHN: Could we have others in the audience give us your name as well as affiliation?
MR. MANSON: Wayne Manson with the Electronic Privacy and Information Center.
MR. WRIGHT: Ben Wright. I'm an attorney from Dallas and author of a book called Electronic Commerce.
MS. WILLIAMSON: Michelle Williamson, National Center for Health Statistics.
MR. GREEN: John Green, National Association of Health Underwriters.
MR. CRUMPLER: I'm Stuart Crumpler with the Food and Drug Administration.
MS. JACKSON: Debbie Jackson, National Center for Health Statistics, NCVHS staff.
MR. LYNCH: John Lynch, Time Trust.
MS. McABEE: Rhonda McAbee, Care First, Blue Cross Blue Shield, information security.
MR. POHASICOP: Mark Pohasicop, Care First, Blue Cross Blue Shield.
MS. WHEELER: Gladys Wheeler, Health Care Financing Administration.
MS. EMERSON: Mary Emerson, Health Care Financing Administration.
MR. RUDDY: Dan Ruddy of the American Health Information Management Association.
MS. NEUMAN: Sherry Neuman, Iscribe.
DR. LU: Simon Lu with the National Library of Medicine.
MR. LAURE: I'm Mike Laure from Silanis Technology.
MS. MEDASSEN: Sue Medassen from HCFA.
DR. COHN: Let me just talk for a minute about how we are setting up the panels for today and tomorrow, as well as comment that for those of you who are around Washington, you know there is a thick fog out there this morning, so I suspect that some of our panelists may be struggling to come in through the fog.
DR. FITZMAURICE: What's new?
DR. COHN: What's new, eh? Actually, I haven't seen fog in Washington before. Usually it is a San Francisco phenomenon.
DR. FITZMAURICE: I think those that were flying in this morning may be affected -- their landings may be affected by the fog.
DR. COHN: Yes, exactly, which is something you're pretty used to in California. I haven't seen it before in Washington.
Having said that, we are going to be having two panels this morning, the first on the overall issue of electronic signature versus digital signature and what are the differences and what we need in health care. After a morning break at around 10:45, we will spend the rest of the morning on the second panel on the business case for electronic or digital signature.
This afternoon after our lunch break, we will be having a panel that talks more about government work around electronic and digital signatures, what sort of efforts have been going on, what sort of standards activities, what sort of pilots.
After that panel, we will be spending about an hour, hour and a half, talking about what we have learned. The point of these hearings today and tomorrow are to try to develop recommendations for the Secretary in this area.
Tomorrow morning, we will hear about reports on existing projects, then once again have a chance to talk further, and hopefully be adjourned by early afternoon.
Questions or comments before we start the panel?
With that, Dave Barnett, would you like to start?
MR. BARNETT: Sure, Simon. My name is Dave Barnett. I'm a security architect with Kaiser Permanente.
A little bit of a clarification. We have had several series of questions come across, and I'm not sure which format we want to use here. Should we stick with the agenda as published? I have answered more than that, but we can stick with that in order to keep in a timely fashion here. Okay.
The first question I'm going to answer is, what is the difference between electronic signatures and digital signatures. This is a very problematic question, because there are hundreds of definitions for both of these, so I'm going to use my personal composite, and things that I believe are generally acceptable, especially in the information security industry.
I define the electronic signature as any method that logically or physically associates electronic representation of the identity of a person with the content of an electronic document or record. This also implies acknowledged authorship or agreement.
One of the things that is important that I believe the American Bar Association has pointed out is, there has to be a conscious effort to sign a document. Many e-mail programs automatically sign documents, and this takes away from the intention. I think an automatic signature is not very meaningful. So part of this is the intentional acknowledgement that yes, this is my signature, yes, I am signing this document, and I agree with it or acknowledge it as an author.
In this context, tying my name at the bottom of an e-mail message or an electronic document is a signature. I think this is a problem in itself, because it is very easy to change that signature. Anyone can type any signature that they want at the bottom of a document. They can alter the document, they can forge a signature, erase it.
Generally with electronic records, it is very difficult to protect the content, and electronic signatures as I have just defined them have very low assurance; anyone can change them. So it is useful as identification, but it is not useful if you are concerned about the content or the authorship.
So I am defining digital signatures as a very special kind of electronic signature. They overcome this vulnerability and they tend to have the same force and effect as a manual or written signature. So I define a digital signature as a high assurance electronic signature.
Common usage. The phrase digital signature is usually reserved for these high assurance electronic signatures. A low assurance electronic signature, which is the normal one, is usually called an electronic signature. So this is logically complex, in that a digital signature is a type of electronic signature, but in common usage they are mutually exclusive. I just want to clarify that, because I'm sure I am going to use this in this context throughout my testimony here.
Some of the characteristics of a digital signature is, they provide reliable assurance that the message or content of the document has not been altered. They also provide signer authentication, which is a verified identity, non-repudiation, which is strong evidence of the validity of the signature and of the data.
Digital signatures have two essential technical characteristics. One is, they cannot be forged or altered without detection and two, if the content of the signed document changes or is altered in any way, the signature is invalidated.
In addition to these technical characteristics, we have two procedural characteristics. The first one is, the owner has sole control over his signature. The use of the digital signature requires an action by the owner, and the affixing of the signature is a deliberate act which serves to approve and consummate the transaction. These are procedural, not technical.
In the American Bar Association's digital signature guidelines, they also point out there is a ceremonial aspect to a signature. The act of the signing of a document calls for the signer's attention to the legal significance of the act. So whereas it may be acceptable in an ordinary electronic signature for a mouse click to affirm or affix the signature, I don't think it is acceptable for a digital signature. I think we need something a little more affirmative, do you agree, or are you aware of. At least two mouse clicks is the minimum, some way to affirm that you really, really mean this, that it is not an accident.
In defining digital signatures, a lot of times you will see the use of the term public key cryptography included in the definition. I really prefer a different approach to this. I think first, we shouldn't mix the requirements and the solutions. I think we need to decouple how we define a digital signature in terms of its requirements with ways in which we can implement it.
Secondly, a problem with adding a qualifier or public key cryptography, I think most people tend to assume that this implies a particular technology, in particular, PKI. I think this is very misleading. The digital signatures in themselves I believe are technologically neutral. The first instance of such a thing was published by Witt Diffy and Marty Hellman in 1976. It is basically a mathematics problem that is easy to set up and very hard to solve. These are usually called one-way functions.
Note here, the caution to this thing is not to get too technical, so if I do, someone raise your hand. I am a techie, so this is my stuff.
Since 1976, there have been three widely accepted families or approaches of these one-way problems that seem to work pretty well for digital signatures. This is definitely technical. There is a discrete logarithm problem, there is the integer factorization problem, and the elliptic curve problem.
A lot of these have been formalized as algorithms, but I'd like to point out, algorithms are formula-less, they are not technology specific. Part of the reasons for specifying an algorithm is, there are some security concerns that are very important with digital signatures, as well as encryption. That is why I think it is necessary to get to a certain level of specificity, so we know that these things work and they are generally acceptable as a good solution. This does not imply that it is technologically specific.
For example, in FPS 186-2, it points out that a digital signature algorithm may be implemented in software, firmware, hardware or any combination thereof. IEEE Standard 1363.2000, which is on public key cryptography, was developed to provide a reference for specifications for a variety of techniques which applications may select.
These are all very general frameworks. They are fairly neutral from a technological point of view. The importance of specifying them is, these are acceptable approaches in information security. We can rely on them. We don't want to have any old approach come in and say, we think this is secure. It would be much to the benefit of someone wanting to forge a signature to encourage the use of a weak scheme or schema for digital signatures.
It is extremely important that we be able to trust the scheme. That is why I think publishing the algorithms and specifying which methods are acceptable would be an important part of the definition.
I think we can do this without getting specific as to what kind of technology is needed to implement these. We are basically talking mathematics here, formulas, procedures. These can be implemented on any platform in a variety of ways, any language. It doesn't involve any particular vendor.
I want to stop before we get to a technical specification, which implies a protocol, like an Internet RFC or something, because that does tend to get technically specific. But we can stop before that and specify, here is the approach that is acceptable to us.
These algorithms for digital signatures can be implemented in code or in a product according to various technical protocols, specifications. They can be accompanied by a supporting infrastructure such as PGP or PKI. Then it makes more sense to say, this is a technology solution.
So I want to stop before we get to that point and list algorithms that are acceptable for use in a security setting that will allow us to do digital signatures. I think that is an appropriate place to stop. This will decouple the definition of digital signature from the algorithms, and then in turn we can decouple the algorithms from any specific technology.
In summary, electronic signatures are any means of affixing an identity by intention to an electronic document. Digital signatures are a special case of electronic signature. They are intended to have the force and effect of a written signature. A digital signature is a high assurance electronic signature that provides strong evidence for non-repudiation, verifiable authentication of the signer and prof of the content integrity of the document.
The only mature approaches today that are available for many of these requirements are based on one-way mathematical techniques which are often called public key cryptography. The algorithms themselves are technologically neutral.
Are there any questions on that part?
PARTICIPANT: David, you mentioned IPS. You mentioned IEEE, but I didn't know what IPS was.
MR. BARNETT: I'm sorry, FIPS, federal information processing standard.
PARTICIPANT: Say again?
MR. BARNETT: Federal information processing standard, from NIST. So it is NIST FIPS publication 186-2, is the digital signature standard from NIST.
DR. COHN: I just want to clarify for the panelists, normally what we do is, we let you testify, all of you, and then we will hopefully have a chance to have some questions and answers as we go along here.
MR. BARNETT: Okay. The next question is, what kinds of signatures should be used in health care and why.
I think there is a meaning for both electronic signatures in the low assurance sense as well as digital signatures of the high assurance sense in health care. For example, if I send an e-mail to my manager asking for the day off, he might respond, okay. I don't need a digital signature for that, unless I really don't trust my manager.
There are a lot of instances where a normal identification is perfectly acceptable. In some cases, for example, a fax is fine, and in other cases you want a written contract that is witnessed. There are many levels of assurance that are needed in any kind of business, and health care is no exception.
One of the advantages of electronic signatures or digital signatures is, they are very easy to implement, and they require little computational or organizational overhead. They are easy to do. Essentially, I can type my name, or you can put in some type of identifier in the e-mail. It is very easy to implement.
One of the problems with digital signatures is, because they require complex mathematics, they tend to have high overhead computationally, plus they tend to need a supporting infrastructure. We don't want to use them for just any old thing. Pick your cases where it is important to use a high assurance signature versus a low assurance. I think there is room for both in the industry.
So whether an electronic signature or a digital signature is used really depends on organizational needs, regulatory needs, that weighs the cost of implementing this against the needed function, and the need for reliance and trust. If we have a requirement to trust that a document has not been altered, and that the signer is who he or she claims to be, then a digital signature I think is appropriate.
This is often the case in a lot of health care things. Orders, requests for records; there are many instances where a digital signature is really the most appropriate method, but not all instances.
The way I look at it, wherever a written signature has traditionally been required by law, a digital signature would be appropriate. Or wherever it is necessary to demonstrate that an electronic record has not been altered since it was written, again, a digital signature is the best way to do this. Wherever it is necessary to demonstrate that a messenger document is authentic and was signed by whoever claims to sign it, the digital signature is an appropriate solution.
If we require digital signatures for all business functions, we have an unnecessary burden. In many cases, an audit trail, an electronic identifier or low assurance electronic signatures are appropriate ways to deal with this. But whenever it is critical to trust in the authentication of the signature and the content of the document, then a digital signature is what is required.
The next question is, what guidelines or standards for electronic or digital signatures are you using. The products that we employ follow the NIST FIPS publication 186-2, which is the digital signature standard, and FIPS 180-1, which is a hashing algorithm used in conjunction used in conjunction with a digital signature. Most of the products also follow FIPS 140-1 validation.
We use the American Bar Association digital signature guidelines, quite extensively. They have a nice explanation of the ramifications of digital signatures, and some good definitions as to what these mean, and the conditions that ought to be looked at.
For electronic signatures, I don't really see that there are any widely used standards. There are for digital signatures; electronic signatures tend to follow more along the generally accepted practices of an audit record -- that is, who did what, when, where, that sort of thing.
Other standards that we use. IEEE standard specifications for public key cryptography, which is IEEE 1363-2000, is a standard we use. One of the things that I like about that one is that it goes to great lengths to be technologically neutral. It separates out some of the definitions. A definition for a digital signature schema, for example, which is a method for authentication, then it will follow along with, in public key cryptography, this means. So they have done the decoupling that I favor. They have the definition, and then they list an approach and say, in this approach this is how we deal with that. IEEE 1363 went to a lot of trouble to keep this technically neutral; it was developed as a framework.
I think this is a very good approach. It doesn't limit us to any particular technology, which as we know changes quickly. But the basic procedures for secure digital signatures, authentication, non-repudiation, I think have to be examined carefully and specified.
Next question. Are there any ANSE standards for these signatures. There are several. Most of them come from the financial industry. For example, we have ANSE X9.31, which is a digital signature using reversible public key cryptography for the financial services industry, ANSE X9.30.1-1997, which is another public key cryptography for digital signatures, and ANSE X9.62-198.
The difference between all three of these, they come from the three types of families or three approaches. The RSA algorithm, the one that is referenced in X9.31. This usually is considered the de facto standard for digital and encryption signatures. It is very popular. That is based on the integer factorization problem.
The DSA, digital signature algorithm used in X9.30 was created as a royalty-free alternative to RSA, although with the expiration of the RSA patent last month, this is less of an issue. But DSA was designed as a signature-only algorithm and not for encryption. It is part of the discrete logarithm family. It is a little bit slower than the RSA, but it is an alternative to the RSA algorithm, and it can be implemented on comparable hardware, software. Otherwise, it is fairly equivalent.
One of the newcomers is the ANSE 9.62, which is based on the elliptic curve problem. One of the reasons the elliptic curve is very popular, it uses a smaller key. This makes it very compatible for mobile devices - PDAs, wireless devices, Palm Pilots, that sort of thing. It is a newcomer and it is becoming very popular. So those are three choices we have based on current ANSE X9 standards for the financial industry.
The next question, do these signatures comply with the requirements for the HIPAA security NPRM. Digital signatures as I have defined them, with a non-repudiation authentication, is a special case of electronic signature, do comply with the electronic signatures as described in the HIPAA NPRM. They satisfy the legal and time tested characteristics of a written signature.
This is how I used a digital signature. They are the version of electronic signature that do meet these criteria. They have the force and effect of a manual and written signature.
The last question, how does the e-sign act work with signatures. We haven't felt much of an impact yet, but we certainly expect to. The e-sign act prepares the way for full utilization of electronic patient records. This is very much aligned with what Kaiser Permanente used as a key strategy for providing high quality and affordable health care.
One of the concerns we have with the e-sign act is attempting to show favor or bias to any particular technology, it appears to forbid identifying specific standard approaches that meet these requirements. This is specifically digital signatures. I believe if we don't specify these approaches, we tend to weaken security. This is a critical issue for us.
Kaiser Permanente has been actively involved in committing to promoting standards in the industry that permit secure electronic interoperability between health care organizations and their business partners. We feel that the interoperability and security are vital to controlling costs and providing quality care in the e-commerce world. The digital signatures are an important part of this activity.
We are not alone in this belief. We are currently working with the California Medical Association to identify and resolve interoperability and security issues in these areas. The California Medical Association is very explicit that digital signatures are required, and anything else would be unacceptable. We need the non-repudiation and the authentication and the integrity services provided by digital signatures in order to trust the e-commerce activities or the e-health or e-care, whatever e-word you particularly favor is appropriate here.
Even though the e-sign act encourages electronic commerce, which is a really good thing -- it is great that it clears the way to allow us to use the electronic versions of signatures. But we are concerned because it is not adequately rigorous enough in defining and specifying high insurance signatures. That is why we feel digital signatures are a more appropriate solution than a normal electronic identifier, and we would like to see some specification about digital signatures and their use in regards to electronic health.
I believe that is the last question on the agenda.
DR. COHN: Thank you very much for your testimony. Ron Beatson.
MR. BEATSON: I am going to do this by presentation, if I can bring this up on the screen. If not, I will not.
I joined Cybersign in the last couple of months. Prior to that I have been involved in the electronic signature industry, and I will say electronic signature as opposed to digital signature industry, for the last 20 years, first in the U.K. and then since 1986, over in the U.S.
The basis of that is that I have been involved in various startups, developing electronic signatures, signature companies which have then gone on to develop the technology in different application areas.
So that is basically my background, and I will now explain what I mean by the traditional electronic signature, which in fact prior to the e-signup came into being has been used in many different applications, and I will explain the major one of those later on.
But essentially, the traditional electronic signature has three separate functions. It captures the signature as it is submitted by sampling the X-Y positions rapidly over time, and so you will therefore have a set of data which is a set of X-Y and sometimes pressure coordinates associated with that signature.
You can in certain applications compare that set of data against a reference template, which could be held on a smart card, hopefully on a client or a local server or even on a remote host.
Thirdly, having captured and possibly verified that signature, one can attach it to a document and bind that signature to the document by calculating an algorithmic based code, which takes into account all the data on the document and attaches that code to the document itself. So that, if in the future that document is changed, then the change will be known by anybody looking at it later, because the codes will not check out.
If I then look at the digital signature and I am going to concentrate a little on the public key infrastructure digital signature as opposed to any of the other algorithms that are used, essentially that public key infrastructure relies on a public key and a private key associated with each installation or each individual or each organization, depending at what level the digital signature is going to be used.
So if somebody is on an Internet, sitting at their work station, and wants to issue a document, the data associated with that document will be encrypted first of all with the sender's private key, and then by the recipient public key, which is known to everybody. A digital certificate will then be generated associated with that process, and issued by some trusted third party.
The data, because it has been encrypted, can then be communicated securely over whatever media it needs to be communicated to get to the recipient. Then when it gets to the recipient, the recipient says, this is encrypted data. It should have been encrypted by my public key and by the sender's private key.
So first of all, I will decrypt it by my own private key, and then by the sender's public key. If that is a sensible decryption, that implies that the document originated from some source -- and this is important -- some source that holds that sender's private key. It need not have been the sender. These private keys are this big. That will become important later.
We basically say that an electronic signature can identify you, the person, and you provide irrefutable accountability for documents that you sign using the process. The PKI takes over from there and provides the security going forward. It identifies the device that you sent it from, it secures the communication, it helps provide the digital certificate, but it does not identify you, the individual.
So then we have the electronic signature e-sign bill which came into being, and that as Dave mentioned broadens the scope of what the electronic signature is. It declares the validity of electronic signatures into state and international commerce. It embraces all technologies. What it does is, it prevents anybody denying that the legal effect of certain electronic documents and transactions signed by an electronic signature.
It also clarifies broad circumstances in which the electronic record satisfies any statute or regulation that mandates a record in writing. It also requires inquiries into domestic and foreign impediments to commerce in electronic signature products and services. So what we have now is a broader definition of what an electronic signatures is, which indeed does incorporate the digital signature, depending on how it is implemented.
So we now have to my mind an increased risk associated with the use of electronic signatures in commerce. We can base it on a password PIN, we can base it on any biometric method which is good, because that actually ties the transaction to the individual. You can submit any sign which indicates your intent to sign that document, and hence, a password protected digital signature would meet that criteria.
However, if we then go forward and say, supposing this document is created down the road and we want to actually see who signed it, it is important for us to be able to go back to that document and say, person A signed this or person B signed this. Therefore, it is very important to show who made that sign. Hence, I believe for that purpose, we revert to the use of the traditional electronic signature.
I believe that technologies for health care transactions need personal identity verification at the network access control level. We need personal accountability and document authentication at the point at which those documents are signed, and we need secure communication thereafter. Those three areas I think will insure the security of that information, as well as generating in my opinion some very significant economic benefits.
We can use the electronic signature in the context of an Internet to attach electronic signatures of the traditional type to documents. We can then use the digital signature infrastructure or the -- most often based on public key encryption to certify that that document originated from a specific source. We have a trust associated with that transaction, which will be accepted, I believe, worldwide.
If we go back to an electronic signature, basically we would use -- I don't know how many of you have purchased products at something like Circuit City, where you may use your credit card to sign on a device like this. That essentially is capturing an electronic signature and associating it with the credit card transaction.
There are today probably about two and a half billion electronic signatures captured each year to deal with that sort of transaction. I believe similarly, we can move that technology into health care to secure those documents.
Let me just talk very briefly about what the application for credit card signatures does. It captures the electronic signature at the point of sale in this sort of device. It encrypts and binds that post transaction to the signature, communicates it to a host, and it is stored electronically in encrypted form until it is archived off at some stage. But if there is what they call a request for copy in that industry, or a query against the transaction, that transaction is retrieved and printed out with the signature in place, and is used as evidence to associate the transaction with a particular individual. Then if there is still a problem after that, that document becomes part of the evidence of the dispute going forward.
One of the benefits apart from the security of this is that there are very significant point of sale savings to the large retailers who have installed this equipment, something of the order of $500 per terminal they install per year, based on costs associated with admin and what they call chargebacks. So basically, their investment is recovered in six months. I believe with the use of the traditional electronic signature in the health care industry, that very similar savings can accrue.
Just to point you to a book by Bill Gates, who has done some research in Microsoft. He reckoned that the paper cost of orders which they do were $145, and when they moved to an electronic order system, the costs grew to five dollars. So that gives you some sort of power of the economics of that transaction.
I wanted to talk a little bit about standards at this time. The standards for the electronic signature format as Dave said are not really -- there is not really a standard for that. but there is an emerging standard called the bio api standard, which is available at a website which is www.bioapi.org. That deals with how you interface biometric devices to your system. Indeed, the electronic signature if it is verified would be such a device.
That has NIST backing. It is government supported. It is intended to cover all platforms, and will be an ANSE standard at some stage.
Apart from that, different companies in the electronic signature field provide what they call plug-ins for the most widely used software, such as Adobe Acrobat and such as Microsoft Word.
For the electronic signature of the traditional type to be used, you need a device -- and this device is smaller and less expensive by the day. Now we have the pervasiveness of the Palm Pilot to consider, which will -- I think at last count there were about seven million of these devices out in the U.S., and they are going now to something like 700,000 a month. These devices would be perfect to actually capture the electronic signature on and attach it to documents with the help of the software which would be available from the various supplies in this area.
I was going to give you a small demonstration; I'm not sure we have time for that.
DR. COHN: No.
MR. BEATSON: With Adobe, we would create a document, capture the electronic, verify that electronic biometrically if it was necessary, attach the signature to the document and bind the signature with the document.
Adobe has software associated with it that cooperates with the plug-in, which would be part of their system, and that would enable the document to be stored and then we can -- prior to that actually, we can invoke the digital signature arena and transmit that document securely with a certificate to the intended party.
That concludes my testimony this morning, and I thank you.
DR. COHN: Thank you very much. Ann Gugel.
MS. GUGEL: Ann Gugel. I am with Baltimore Technologies. I am a market development manager for health care businesses in the U.S.
Baltimore is a leading provider of e-security solutions globally, and with a strong emphasis on public key infrastructure, technologies and services. I'm going to quickly go through the questions so we all have enough time here.
The first question is, what is the difference between electronic signatures and digital signatures. I have to say that I agree with Dave Barnett's definition. He did a great job in describing differences.
I just want to point out that he mentioned that electronic signatures were use for identification. I tend to disagree with that. I'd like to say that digital signatures are very useful for identification, because when digital signatures are used in a public key infrastructure, there is a lot of checks and balances and measures of trust in there that are not inherent in an electronic signature system that doesn't employ PKI. So those checks and balances include certificate authority and registration authority. That registration authority would provide the strong identification needed and a third party of trust that is standing behind that identification. Those are the benefits that a public key infrastructure brings to use of electronic signatures in digital certificates that is not available in other types of technologies. I know we want to stay technology neutral, but I did want to bring up that one point.
Digital signatures can be useful for both identity or encryption. You can separate your certificate and have two certificates, one for identification and one for encryption. We recommend for security reasons you want to have encryption in your system, but there are providers out there using digital certificates solely for identification.
The next question is, what kinds of signatures should be used in health care and why. This is really up to the type of data that needs to be protected and the level that the organization wants to protect that data. Of course, I believe that digital signatures are required for strong identification and strong authentication of the person with the trusted third party standing behind that. However, those electronic signatures such as a digitized handwritten signature also prove useful in health care, because a lot of documents, people want to see a signature for approval on it, and a system of approving documents and adding counter signatures. So there are multiple technologies that might need to be added together to provide the best solution for the electronic signature in health care.
The third question is, what guidelines or standards for electronic or digital signatures are you using. I see this question very similar to a further question that talks about standards.
The standards that Baltimore has developed include the ISO standard for digital certificates. X509 is the standard for the digital certificate in a public key infrastructure.
Also, we adhere to the IEEE standards that Dave mentioned, 1363-2000. As far as encryption goes, our systems provide DAS or triple DAS as well as RSA algorithm and elliptic curve technology or the newest algorithm approved by NIST, the advanced encryption standard.
Users can choose to use whatever algorithm they would like, so it is not mandated. We provide the capabilities, users decide how they want to use our technology. We also adhere to standards that aren't really open, but they are default industry standards because some of the major vendors like Cisco have developed these standards, and they are widely used with Cisco products, such as the SCEP certificate enrollment protocol.
There is another standard for certificate management protocol that is not really -- that is widely implemented as well throughout the PKI vendors.
The fourth question, what is the value or major benefits of using these guidelines or standards. Those benefits are that you have -- with the use of standards based products, you have a greater degree of interoperability among the vendors, and scalability can be enhanced. It also provides users strong flexibility, that they are not tied in to one specific vendor or one specific product when most of the leaders in the industry are adhering to those open standards.
The fifth one is, what are the limitations or the weaknesses of the guidelines or standards. We all know that it is how it is implemented. A poor implementation can happen with anything you buy. This is not plug and play technology. You don't just buy something from Baltimore or any of the other major vendors of the PKI, plug it in and expect to have a PKI system that is up and running, and all your policies magically appear just the way you wanted them in the system. Public key infrastructure is a combination of software, hardware, people, policies and the implementation architecture, and it does highly rely on the rest of the security of the system, including network security, audits, risk assessments to make sure that other holes are plugged in the system as well.
Are there ANSE standards for these signatures. Dave addressed that pretty adequately, so I'm going to move on to number seven.
Do these signatures conform to the ASTM standards for health care. Yes. I also have a copy of the E31 standards for the electronic signatures before me for referral, if anybody wants to take a look at those.
Do the signatures conform to the NIST 186.2. Yes. We give the option of using DAS or triple DAS.
Are there other widely used standards for this type of signature. Yes, there are. I addressed that a little bit in a previous answer, but it is PKCS standards and the PK standards are widely used by other PKI vendors for digital signatures in a PKI.
Do these signatures comply with the requirements of the HIPAA security NPRM. Yes, they do, but I do want to emphasize that no single vendor provides all the capabilities required in the security electronic signature NPRM. We may provide technology solutions, but we may not provide the training and awareness needed for that specific organization. I don't know of any vendor that provides all the risk assessment services, robust auditing of all the systems in combination with robust auditing. Auditing is one of the requirements right now. That includes auditing of everything, not just the process of requesting digital certificates or how those certificates are used for access control.
Auditing logs include all the logs from NT Solaris HP systems and consolidating that, so that requires a number of different vendors or professional service providers. That is why it is important that the major vendors have partner programs. We have extensive partner programs with probably hundreds of partners that we have done some interoperability testing with.
How does the e-sign act impact your work with electronic signatures. The e-sign act as described by the two gentlemen before me, it brings a level of legal validity to the transactions. There are a few cases specified in the e-signature act where e-signatures cannot be used, leaving all other cases available and open for the use of electronic signatures and having them hold in a court of law.
Unfortunately, the e-signature in the global and national commerce act is very broad in its definition of what an electronic signature is. I see a lot of weakness here, and a lot of room for lawsuits. It is going to be difficult for individuals to stand in front of a jury or a judge and try to defend the technologies they used. I don't see any technologies stronger than a PKI system for great scalability, global interoperability among multiple vendors and outside of a private network, that can provide all of the checkmarks needed that I would like to stand up in the court of law.
As I mentioned before, partners are very important in this. I would say that time stamping might be a very important feature to have when you are trying to defend a legal signature. In addition to that, in a PKI, you may be interested in having an OCSP server, which is an online certificate status protocol, where you can have instant validation and checking of the validity of a certificate.
So those are two pieces that off the shelf PKI might not provide, but there is a third piece, a hardware signing module. That is where the FIPS standards come in. There are FIPS standards for hardware security signing modules from level one through level four, four being the most stringent. So to have the highest assurance possible, you want to have all those extra pieces in a public key infrastructure, including a hardware signing module, OCSP server and some time stamping in there.
I'm going to skip down to 13. Is it possible to apply multiple signatures to the same document, and is it also possible to apply counter signatures. Yes, it is, but that requires maybe an additional piece. We have a product called Forms Secure. Our Forms Secure product allows you to put multiple signatures and counter signatures in there.
There are other vendors that focus specifically on this type of capability, and they would be partnered with digital certificate companies. That provides a real nice system of having counter signatures and multiple signatures for tracking through a system, along with the strength of a trusted third party and digital certificate.
The next question is, what kind of software is available to support this technology. Our system runs on NTs, NT 4 or 2000, HPS and Celeste systems, most of the larger implementations of operating systems.
Can signatures be used to apply to whole documents parts of documents, binary files and EDI files? Yes, and I specifically wanted to address the EDI files. A lot of the EDI vendors are now leaning toward XMLs as the EDI of choice. There is an electronic signature for XML signing, so it is possible to sign parts of an XML form.
How large is the install base for this type of signatures. We have two very large customers. We are a global company, so a lot of our implementations are in Europe, Asia and the U.S. We have large implementations in Australia, the Australia Health Insurance Commission as well as the Australian Tax Office are two of our larger customers.
One of the largest ones is in the financial industry, ABN Ambro is another one of our large customers. Baltimore is being used as the route certificate authority technology for the Identrus program.
This leads me into the next question. Do you think that there are digital signature solutions in other industries that can be used for health care. There are two that come to mind readily. The first is the Identrus model being used in the financial community, and the second is the federal CA technology that is being used in the government. I see that Rich Lido is on the schedule later today, so I assume he is going to talk further about bridge certificate authority, the concept and how they are using that, and the benefits of not having one route set, but having a bridge concept.
Does the verification of signatures require access to a central server such as OCSP. The answer is no, it does not, but that does bring additional assurance, if an organization would like to implement OCSP.
That is all I have. I tried to be brief.
DR. COHN: Thank you very much. Michael Laure.
MR. LAURE: Thank you very much. I think copies of the presentation or information regarding the answers to these questions are being passed out right now.
Before I jump into the questions, I just want to explain a little bit about who I am and who Silanis is. Silanis Technology is working on developing electronic signature technology as well as the market expertise for almost a decade now, so we have done the enormous amount of work of actually putting electronic signature applications into a whole variety of different industries and costumers, some of which I have listed here, that include not only government, but pharmaceutical, health insurance, financial and so on.
Just to mention myself, I am one of the co-founders of the company. I have watched the market evolve since about 1991, and it has been pretty interesting from the point of view of electronic signing as opposed to the digital signature aspect, which I will talk about in a moment.
Just to put a context around it, the products that we produce are based on a product called Approve-it. It is essentially an electronic approval management application that is based on secure electronic signatures and approval process automation. It uses electronic signatures however that are perhaps a bit of a hybrid of what you see. What they do is combine the digitized handwritten signatures with digital signature technology, and allows us to scale into all of the various technologies and standards, provide the security to these processes.
In our case, most of our customers use what we call captured signatures, which is an encrypted file containing not only imaging information about themselves, but also all the security technology to insure the authentication as part of that. And of course, we have had to provide the ability to use those signatures in a whole variety of signing processes, as well as different document formats.
So the questions. When I looked at these, the answers I have come up with here are from the point of view of our company and our customers, as opposed to the general marketplace.
The first question that I wanted to address, which I think has been interesting so far, and I think I wanted to add the comment that if you took all of the products and peoples' concepts in this room and put them together, you probably would have a pretty good product at the end of it.
The biggest problem that we are dealing with as a company who is actually out there selling this specific type of capability is the massive confusion between the terms between electronic signatures and digital signatures. So I would say the confusion right now is, most people perceive electronic signatures as the digitized handwritten signatures, for the most part. Occasionally they may perceive it as having biometrics built into it as well, but that is pretty much they way they see it, with no security. So that obviously is a problem.
The second type of signature we're talking about here, digital signatures, sometimes is perceived as, this is how I sign on to the computer or signing with a PKI, or maybe a few people really understand that there is cryptographic technology that we are talking about.
The reality of the difference between electronic and digital signatures is that electronic signatures is a computer based method by which we can express the same legal meaning as a paper signature. The interesting thing about this from a market point of view, because to a great extent what we are dealing with here is semantics, more than anything else, is that there is well over 100 pieces of state legislation, there is all kinds of pieces of federal legislation, and the vast majority of these pieces of legislation talk about electronic signatures. Within them, they may talk about digital signatures as the method by which we will do that, and in fact, the NPRM that we are discussing here today, this is exactly the approach that has been taken.
So from our point of view, electronic signatures represents the method by which we do the equivalent in the computer world of what we do with a pen. What that really means, one of the best places that we have found to find a definition of that is the Uniform Commercial Code, because this is what governs virtually all commercial and financial transactions at a fairly high level.
The Code defines a signature simply as a mark or symbol or signer's intention to authenticate the writing. So the intention to be captured and to authenticate the writing is key to it. That was actually how our company got started. Someone said, can they get a signature into this autocab drawing, and once it is in there, can we make sure that if it ever changes, that it invalidates the signature. We came up with a way to do it.
So that is pretty much what signatures is. If you look at the e-sign law, what they have come up with on a technology neutral basis is stating that electronic is bound to and will process attach to and logically associated with the contract or the record. And most importantly, executed or adopted by a person with the intent to sign the record. So we are just stating what UCC is saying, except now you can do it in the electronic world.
So in reality, I have an acceptable electronic signature that goes beyond the perception of a simple digitized handwritten signature. We have to have a process that captures the intent and then secures that result, that signature, so that it is bound to the signature record, using some type of security technology. By default today, the baseline for that is digital signature technology.
The reality with regards to the digital signature is the only place where you have clear and proper definitions of this is if you look in a cryptographer's book like Bruce Schnei, for example, who will tell you what an additional signature is. It is a cryptographic process that doesn't insure the integrity and the origin of data. I thought Dave Barnett did a good job of explaining that this is what it is. It is a technology, it is a horizontal kind of a thing.
By itself, it doesn't represent intent. It doesn't capture peoples' intent as part of that process. So to come out with something at the end, you have to put these two technologies together. I think the only thing I would say is, the way I would put those two together is that electronic signatures are in fact a subset of digital signature technology to some extent. If we look at digital signature technology, it is used for all kinds of things like VPNs, website access, secure e-mail, and of course electronic signing, which is an application of that type of technology.
In order to use it, it comes back to what we said before; it has to be incorporated into a computer based process that specifically captures the person's intent with regard to that data or to the document. You have to reproduce what you are doing on paper in the electronic world and make it at least as secure as pen and paper. Preferably, we would like to make it more secure, and that is certainly possible.
So that is our point of view on electronic and digital signatures. In the end, it is what we end up having to explain to a lot of our customers. If they go out with the idea, let's go out and buy digital signatures, and they call up say a company that has a toolkit like RSA for doing that, they probably wouldn't be too happy about having to write a whole pile of code in order to have an application. They want to have something that is an application that defines for them the signing process, so they don't have to worry about if they are doing it right or not.
To move on to the second question, what kind of signatures should be used in health care and why. Electronic signatures are inherently the equivalent of legally binding signatures. When you look at definitions coming back to all the legislation and various regulations, and the reality of what they are, this is what we use to sign. We have to get that intent, and we have to secure the intent as part of that signing process.
I use the word legally binding signatures here. Sometimes people tend to think of legal as only applying to contracts or something from this nature, and nothing could be further from the truth. Any piece of paper with a signature could end up in a court of law for whatever reason. It could be a timesheet, it could be a purchase requisition, it could be anything, and that signature has at that point a legal effect on it.
So in health care, in essence, you need electronic signatures. However, the electronic signatures will need to incorporate digital signature technology as the baseline of its security that allows us to insure that the signatures that are being applied to the document, not only have we captured the intent, but that we can also verify that that really is that person who signed it, and that the integrity of the document or data has not been modified since the signature has been applied to it.
So that means that on top of having digital signature technology to go with it, we also then have to start thinking about identifying the security pieces which Anne Gugel talked about before, and I think that her point was very well taken. If you are going to have this type of technology, you also now have to start incorporating the registration process into it.
What is the best way to do it? Well, digital certificates are a very good way to do it. There are other ways to do this as well, though. We found that there are different ways that you can take PKI technology, digital signature technology, digital certificates, and there are different ways you can put them together that don't necessarily result in a certificate authority.
CAs are good. It means that I am putting a certificate into every person's hand out there, and in many cases it becomes extremely cumbersome. There are other ways to do this, however. So by putting a specific technology or more specifically a specific kind of a product or implementation of technology into the regulation, puts an unnecessary burden on the regulation at that point. It means that you may be limited to one way to do it, which may prove to be very difficult. If companies come up with new and better ways to put those building blocks together, you're going to be locked out because the regulation has already been made.
So coming back to this, the digital signature technology has to be reinforced with digital signatures, which means that you are going to have to have a PKI system. It also means that you may in certain situations, depending on what you are dealing with, if a doctor is going around in a hospital, we want to be sure that they are meeting the right people, we want to give them something that they can identify themselves.
At that point, you have a choice of three things. You have passwords which can be used on lock certificates, which can be done in a very secure way, except for the fact that people tend to forget these passwords. Secondly, you can use smart cards, which are fairly easy and have become fairly common. I think the U.S. Department of Defense is going to have a really interesting experience with that over the next few months. Then finally, you can use biometrics as well, which adds a fairly high level of user authenticity to the process, but it still boils down to, can we get the technology to work flawlessly in this kind of environment.
A doctor or nurse or any other kind of a health care provider is not going to want to be struggling with technology all it is meant to do is simply sign something. At the end of the day, signing from most peoples' point of view has to be extremely simple and it has to work all the time.
So electronic signatures in health care, the next question that came up, was that they should provide manifestation of the signer's intent. In this case, we feel that a digitized handwritten signature is highly desirable in the documents that are being used in health care.
Part of the reason for this is, a lot of the documents are not being used inside of a closed system. They have to move around. They have to go between health providers, between hospitals and insurance companies, or they have to be documents that interface with the public. And throw into that that a lot of the people today who are working with this do not necessarily feel comfortable with a signature-less process. That means no handwritten signatures. So to some extent, it helps the transition process.
To another extent from the legally binding point of view, when I sign a piece of paper -- and the best example of this is a contract -- when I sign a contract, the validity of the contract, whether it will be enforced or not will depend on whether or not each of the parties understood what they were signing off in the first place. If it is not clear to them that they were even signing a document, and in the electronic world, with certificates being added to things like e-mail, this can become extremely confusing, to say the least, then it is possible that the person will not realize that they were signing the document, and the document will not be legally binding, or can be shown to not be legally binding as a result of that.
So the handwritten signature adds a great deal of value, because anybody who signs with a handwritten signature immediately understands what it is that they are doing at that point. So it is quite obvious to them. However, the process is there to automate and to some extent hide from the user what is going on in the background, which is security. That allows us to insure that the signatures are in fact valid in the highest sense possible.
The next question was with regards to what guidelines or standards for electronic or digital signatures is Silanis using. Well, to start with, before getting into actual guidelines, the thing that drives us the most tends to be what our customers are doing. A lot of the markets that we deal in are regulated or managed in some fashion or other. So we are talking about pharmaceutical, government, financial, telecommunications. In each case, if we are not dealing with a specific regulation such as the FDA CFR 21 Pub 11 or the DoD PKI standard or CHPIA, we are dealing with the insurance companies' requirements for how they need to have contracts signed, or the financial industry for how they need to have enrollment done, or any other company's requirements on how signing should take place. Signing in the end for them is dependent on what their business processes are. So we always have to make sure that we are meeting those specific requirements and guidelines that are coming from the markets and that customers are dealing with.
In addition to that, one of the guidelines that we use and we refer to frequently is the American Bar Association's digital signature guidelines, which was also mentioned by Dave Barnett before. Specifically, it gives a good definition of what signing is, but more importantly, it gives a fairly good definition of what the characteristics of an electronic signature should be.
We find this in some state legislation as well. One of the state regs that we use quite a bit is the New York State electronic signature and records act regulations, which are similar to the ABA's. They define the characteristics as requiring user authentication, requiring document integrity, but also capturing the intent of the person who is signing this.
The New York State reg actually goes a little bit further in defining user authentication as being something that is unique to the person who is signing, being under their sole control when they are using it, and then finally as being verifiable as belonging to them.
From a technology point of view, we use a lot of different technology, but the key standards that we follow on this side are the U.S. federal information processing standards, specifically FIPS 186-2, which defines the use of digital signature technology in the federal government.
In their case, they allow for the use of two specific algorithms. One is the digital signature algorithm as well as recently, they have added the use of the RSA algorithm, which is now what we use. We used to use the DSA, but we preferred to move over to the RSA, since it has such a wide amount of usage in the marketplace.
The other standard that is also part of this and is fairly important is FIPS 180-1, which deals with message integrity. That in itself is an essential part of the other standard and of digital signature technology.
So those two standards together basically define the basic technology that is required to implement everything else that rides on top of that, all of the building blocks that are put together.
In addition to that, we also follow one other standard, which is the X.509 version three standard for digital certificates. That is an important standard from the point of view of how am I going to identify who this digital signature that was put onto this document, where did it come from. The main way to do that of course is through digital certificates, and X.509 is a well established standard from that point of view.
Looking at electronic signature relative to these standards, I know this is a problem that you are wrestling with, our point of view on this is that there are a few basic standards define the core technology. Everything goes through these digital signature algorithms or through the authentication algorithms, and of course, the digital certificate is the other key piece that fits into this.
There are also symmetric encryptions such as DAS which we also use, which is also a federal government standard as well. Beyond that, everything else is taking these building blocks and putting them together so that they work together. But as long as I know that these standards are being used in the signing processes, I will always be able to go back to my signed documents and be able to verify the integrity and where those messages come from, and be able to access the information from it.
Being able to then use it for interoperability is also possible, and that obviously is going to potentially require standards at a higher level. But initially, you have to start building it at a lower level before you jump up to those higher levels, and allow the technology to evolve correctly.
What is the value or major benefits of using these guidelines and standards? The main value, the major benefit of this is that it provides not only us, but also our customers in the marketplace with clear business, legal and technical requirements as to what an electronic signature should do. Part of the guidelines and standards often tend to be focused specifically on technology, but we also have to be aware of what business requirements are, especially when you are talking about things like the insurance industry or financial industry, is going to be key, and of course the whole health care industry, the ability to be able to exchange data is absolutely key.
There was some discussion from Anne before about the use of XML. XML is going to be a core piece of being able to move data around within the health care industry. A digital signature standard on how I incorporate the use of digital signature technology based on the standards that we already talked about into that has already been defined to a certain extent by the W3CI. So that gives us an idea of how we can use that standard towards that end.
Also, just as a point for our customers in the marketplace, it is that it allows them to make informed choices about what those requirements are. So most of these standards are fairly clear in terms of what is required to be able to use them. However, the question comes right after, what are the limitations or weaknesses of these guidelines and standards. Well, there is a number of issues in them. The one that we run into often, because we do deal with the government, is that they are not always followed as they should be, and sometimes they are applied where there is no real need for them.
I would say quite often there are a lot of people who are not necessarily aware of what the standards are in the first place. So you really have a lot of inconsistency as you move about that, and it gets more complicated, once you go into industry, because within industry we have different groups who are all trying to regulate what they are supposed to do. In some cases it is dead clear. If I'm working for a pharmaceutical company, I am going to conform mostly to the FDA's regulations. If I am working in the insurance industry, it is getting kind of confusing. I've got state level regulations, I've got federal level regulations, and it is not always obvious as to which one is going to come into play.
From the point of view of electronic signatures, it gets even more difficult, because now I have to decide whether the state where I am working has a regulation that is supposed to apply to me, and there are other regulations that provide what the e-sign law says.
DR. COHN: If you could begin to wrap up, please.
MR. LAURE: Okay. The other points that I would like to point out is that sometimes the regulations tend to focus too much on the technology and tend to overlook the process issue, such as the requirements for registration and identification process, which I think Anne covered quite well before.
Industry and government standards, fairly quick comments about this. Are there ANSE standards? For the types of signatures that we do, there is nothing specific about it, but then again, we are basing our security on digital signatures and certificates. So all of the standards that were discussed prior to this apply in that case.
Do the signatures conform to the ASTN health care authentication standards. I have to say that our company was not familiar with these until we looked at this thing. We pulled out the standard and looked at it, and was able to find that we do seem to meet pretty much its requirements.
Do the signatures conform to NIST 186-2. Yes, we do. We use the RSA algorithm for that. We also conform to FIPS 180 as well.
In industry and government standards, are there other widely used standards for these type of signatures. With regards to digitized handwritten signatures, obviously there isn't, although the display of them is quite simple, and there is standardization for that. But again, the security comes back to the digital signature side of it.
Finally, do the signatures comply with requirements of HIPAA security NPRM. In our case, looking at the different components regarding the electronic signature security standard, there is a standard defined, there is required implementation features, and there is optional implementation features. We meet all of the requirements of all of those features within the standard.
As far as the legislation goes, how does e-sign impact our work with signatures? It really has no impact, since we already surpass the requirements of that legislation, since our product is made specifically for signing in the first place.
However, it will certainly force companies to move ahead and establish specific applications as the market leaders, so I think there is an impact it will have there.
The UCITA impact, again, it doesn't have an impact, because UCITA is consistent with e-sign, in the sense that it meets the requirements of e-sign to accept what it does in e-sign.
As far as the technology goes, there are three questions. Is it possible to apply multiple signatures to the same document? In our case, yes. Is it possible to countersign? Yes. Can signatures be applied to whole documents or partial documents, binary files, EDF files? Yes, these are all standard features built into our product, which was designed specifically for signing in the first place.
What kind of software is available to support this technology. Signing is an act that is taught in readable format, so the signature is in fact effective. Our products therefore have to interoperate with the electronic document and forms format. They are required to use these signatures in the first place, so as a result we support Microsoft Windows desktop applications as well as browsers. We support having the applications running up on an NT server as well as ASP applications, and we also support UNIX and Mac based web browser applications.
Does the verification of signatures require access to a central server such as OCSP and so on. No. The validity of the documents can be verified on a stand-alone basis. The verification of the certificate that is associated with it if you are using one and it is tied into one of these databases, can be verified as required or when the document is being verified. In essence, this actually mimics the entire paper process. When I get a signed document, I'm going to verify the signature at the moment that I need to do it.
How large is the installed base for this type of signature. I would say that overall, if you are talking about captured signatures, we are talking probably a half a million signatures. I can tell you that our base of signatures has tripled in this past year alone, so it is pretty significant.
The other industries that I feel really could have an impact here we that are very familiar with is the FDA regulated industries, where they have a fairly specific rule for these electronic signatures. There is a lot of work and a fair amount of implementations that have been done with those type of electronic signatures in that industry.
Finally, in conclusion, I would say that electronic signatures and digital signatures are both necessary, as they each provide the necessary parts of the solution. On the one hand, the electronic signature is automating the process for the capture of the signature's intent, and maintaining the authentication of the signed document as it goes through the approval process, whereas the digital signatures and associated technologies such as PKI will secure the integrity of the data as well as the authentication of the person involved in the signing.
In the end, a good electronic signature product has to be easy to use, has to be secure, and has to work anywhere. It will have to meet our customers' and our users' expectations, so that it will be accepted, and so it will be effective in the end.
That concludes my presentation.
DR. COHN: Thank you. Peter Waegeman, welcome.
MR. WAEGEMAN: Thank you very much. I would like to apologize for having been late. I haven't heard the first presentations, so I may say things again. Please accept my apologies. Also, I feel bad that I just have heard about the confusion about electronic signatures and digital signatures. I feel personally responsible; in ASTM about six years ago we created the distinction. We came up with the electronic signature.
Let me explain. In 1994, ASTM formed the subcommittee on electronic signatures, at that time on authentication of health care information. It was a very well attended group that we had at some point, 28 organizations represented in that organization. We had the joint commission, DoD, AHMA, American Bar Association, AAMT, ADA, the FDA, and the board of ASTM at the time. The various medical specialties, as well as the Justice Department. All of them were there.
Now, as we met for one year on a regular basis, almost every four or six weeks, we went into the various uses of digital signatures. As we went through it, we got to a point where particularly for medical specialties, a digital signature is a transition sometimes too cumbersome, and can be too expensive.
Out of it, we came up with the term of electronic signature. An electronic signature is something where you don't need all of the burden of a security infrastructure, including registration authority, certificates and so on.
The ADA particularly was very vocal in saying this, that a single dentist should not have to buy certificates at this point, but should be able to have out of their own organizational authority some kind of identification. So what we really have created is first of all is the standard which by the way has now been for five years a national U.S. standard. ASTM is one level up from the normal standards of the organizations we are dealing with, the ASC X12, which is an ANSE accredited organization. ASTM is the founder of ANSE, and therefore is a much higher level of an ANSE standard than any of the standards we normally deal with.
So as we move into a standard, we have pointed out after long discussions what are the specialties for health care, why do we need for health care specific standards, something which has been coming up in the meantime in many other countries. In my second talk, I will be talking about at least eight countries I am quite involved in, where in the last couple of years have bypassed what we are doing in the U.S. and are far ahead in the implementation of signatures and PKI. But all those have accepted what we just have heard from Michael, for instance, standards which apply to digital signatures.
In health care, you cannot function with general standards for that. Let me give you a few examples. If we just go into the major elements, if you look at a signature it has five elements. The first one is to identify a person in a way that cannot be faked or cannot be seen in different ways. This goes into PKI.
What we have to understand here is that health care has very different requirements than, for instance, banking or electronic commerce or any other field, where you just need to identify, is this person authorized. We need to know more in the future as we share information on a national and international basis, whether that one person who wants to access information or is writing information, is not only M.D., as he would be in electronic commerce, but is this person licensed in that state, what is the specialty, is he an attending physician to a patient.
We not only need to know, is this an M.D., but is it for instance a psychiatrist, or is it a pediatric psychiatrist. So we need to have identification attributes which are part of the standard 1762.
The second one is that we have in health care requirements for more signatures than one. It doesn't occur in banking or in any other area. The worst case we have identified, and I can't recall the details, are 17 co-signatures, someone is testing, doing research, and someone else is doing something else and so on.
We need to have a signature system which is specific to those requirements. The third part is that we need more than in banking or in e-commerce a specific document structure. A document structure means that we cannot see an amendment of a medical record which is only part of a note. The signature must require that this amendment comes up when the main document is seen at the same time. Again, this does not occur in electronic commerce or any other field.
If you look at the five elements which make up a signature, the first one is for identification. We have in health care way different means of identification. We have said in the interim period, we are willing to allow an electronic signature which has less identification requirements of PKI, which requires a registration authority, certification authority, and so on and so on.
The second part is for signing itself. The signature has to be done in a conscientious responsibility taking effort. It cannot be done as some commercial systems are doing, by default. You have a legal responsibility for it.
For the signature itself, there are many standards out there. I think you have heard of some of them. Most of them apply to the general e-commerce field and so on.
The third one is for the sealing process, encryption and sealing. Once a signature is attached, that document should not be changed in any way, and if it is just a transmission from one company to another one, and a couple of bytes are changed, the signature must be removed. It doesn't happen with many commercial companies at this point.
The last one is binding. A signature has to be affixed to a document in a way that no person, willfully or otherwise, can remove it. There are many ways where in some of the commercial systems right now you can find ways to detach a signature in one way or another.
The last one is what I talked about, the document structure, where one has to be clear about amendments and has to be clear about what is going on there.
So what we have to realize is that the electronic signature is allowed according to the ASTM standard, if there is an authority within an organization, for instance just one doctor. The moment the one doctor is in bilateral communication just with an insurance company, just with one hospital, that could be accepted. The moment this individual deals with a pharmacy in the wide range of the health care field, it will not be accepted. Then we need to get into what is called the PKI.
Now, let me talk a few minutes about PKI. I think they have probably explained it well, but just so we have a common understanding.
PKI is an infrastructure. It is not attached to a signature. It is a very shining concept similar to electronic patient record systems. No one has implemented a full electronic health record system, no one has implemented a full health care PKI at this point.
I spent last week a couple of days with the ministry of health in Singapore, which is probably one of the most advanced ones, and they are almost there. But there are so many elements of the infrastructure. So it would have been better to talk about this as a pure infrastructure than PKI. This is where we have to move to, this is what is really needed.
So to come back to the questions. I think I explained the difference between the electronic signature and the digital signature. The digital signature is part of the infrastructure of PKI. It is what we all need, but it is very difficult to get. It is somewhat complex to manage, it is cumbersome to manage with certificates and so on. Therefore, people are kind of holding back.
In my next talk in the next panel, I will be describing what the impact of that is. I personally see that a switch to PKI is the same situation we had 250 years ago, to go into a general banking system and printed notes. At that point, people just had individual coins, they couldn't see why you are going into this cumbersome system, where you have to go to the bank and where you have ways where you can go anywhere in the world with your printed bank notes and do that.
It is similar in scope. It is not easy, it is complex, it is difficult. However, the longer we wait, the longer we will just have wasted health care costs. I will be showing in the next presentation that the savings are between $50 and $80 million, and it is much bigger in savings than what the paper transactions are trying to do at this point.
So if you look at that, you can see the differences. Electronic signatures can be a transition part. However, I should say that many of the countries I am talking with who are currently implementing PKI systems, Canada, Australia and so on, are saying why did you ever come up with an electronic signature, it makes it so much more confusing. I feel that the ministry of health should just say it should be digital signature and PKI, period. So I have to admit that I bear some guilt here.
What kind of signature should be used in health care? If I would have to decide today, I would say if we could, probably we would move more towards a digital signature and PKI than allowing an electronic signature. However, taking in the fact that we have many signature systems being installed and many being marketed, and very few of them complying with the requirements we have in health care. It may be worthwhile that we see these as a stepping stone to get into PKI and digital signatures.
ANSE ASTN standards are nationally and internationally recognized standards in this field. This applies to 1762 as a general guide as well as a specification for digital signatures.
At the same time, we should recognize that ISO TC215 is moving strongly into an international standard for signatures. It is based largely on ASTM standards and people like Dave Barnett are very much involved in that. People from major countries of the world from Japan, from Australia, Europe and so on are following the lead of the U.S. standards for what has been done in ATSM and is being done right now.
So in regard to standards, we have a good number of standards. Remember, those are for health care. I will show in the next presentation that we need to override the state laws. We need to look at some of those issues, because we have to focus on what are the health care requirements.
When we look at the e-sign act, I will pass out later on a document from the standard magazine which says clearly, e-sign act makes electronic or digital signatures legal. It does not validate them. So what we have to realize is that we can now have electronic signatures, but it does not mean that they apply in health care or documents signed under these general guidelines, would pass as a health care legal document and legally signed.
I think we have been late, and I will keep it short at this point.
DR. COHN: We may have a chance later on to also make comments. We are a couple of minutes late here, but I think we should provide questions and an opportunity to ask questions of the panel before we take a break. Questions?
DR. ZUBELDIA: I want to thank the panel for the wonderful job they have done. I was going to come out of this with a common understanding of electronic and digital signatures, and it is better than that; I have five common understandings now.
The general theme that I am hearing is that there are several parts to a signature. There is the ceremonial part of the individual voluntarily signing, and that can be expressed by a biometric, because you cannot delegate, or it is difficult to delegate that.
Then there is the signature card concept, of a third party -- the registration as to who the signature belongs to, and the certificate authority PKI concept. Then there is the document management part that Peter explained so well, where if a document is signed, it is signed forever, you can't remove the signature. If the document changes the signature it is invalidated.
Is there any these technologies or methods that incorporate the three aspects? Maybe Silanis is the one that comes closest. One thing I noticed in Michael's presentation, you were saying that his meets the larger requirements of HIPAA. Peter Waegeman was saying no, no, no, no, no. Is there a conference of all this that leads into something that could be adopted as a standard?
MR. LAURE: I don't know that there is a standard that just exists and meets all the requirements of HIPAA. In order to meet many of those requirements that are in there, you have to write an application that can manipulate the security technology to perform a number of those things. Some of the basic requirements -- or the very basic requirements are met by a digital signature to some extent, but a digital signature does not guarantee that the person who applied the digital signature is in fact who they say they are. That is probably one of the noticeable aspects in the HIPAA rule that you might expect to see. At least you see it in the state legislation. It talks about digital signatures, but it doesn't talk about things like certificate authorities or registration authorities or how we are going to handle that aspect of it.
There certainly are products and methods to do that out there. But some of the optional requirements of it actually should be mandatory requirements. For example, putting mandatory signatures onto a document doesn't seem like an optional thing for most documents. I think you have to have -- there are a lot of documents that absolutely have to have multiple signatures.
The concept of counter signatures, where I have to know the order the signatures are applied, is mandatory in many business processes. So the problem that we found in implementing our product was that we can take whatever technology, whatever the standards are, and apply it to a specific document structure, and we can make it so that the signature becomes a permanent part of it, but we also have to make sure that it is capable of performing the business processes that are involved with that document.
So if that document is a five-part form, and it requires four signatures and it has to allow for sections to be filled in between the signatures, then the application has to be able to manipulate the technology to do that.
In the end, that is pretty much what we do. We are an application that makes use of that technology and the standards that are out there. The results of an electronic signature that ends up going into the document is based on standards, to the extent that I can verify the signature because it uses RSA for their digital signature and it uses SHA 1 for the hashing of the data, so I can verify the integrity of the document as well. If it has got a certificate on it, I can go and check it against the database.
But the way I put those together to put it into the document, there is no standard for that. It is hard to build a specific standard, because you are trying to build it to apply to all these different business documents or processes that are happening out there. That is pretty much what we run into in dealing with our customers. There are thousands of different types of documents that have to be signed in all kinds of different ways, depending on the industry that you are dealing in, and it becomes virtually impossible to separate the business process from the technology required for the electronic signature itself.
So I don't know if necessarily what we were saying is different. One of the salespeople who works for me had a good expression, which was, basically it sounds like we are all in violent agreement here, and we are just coming at it from different directions as to how that actually happens.
So I don't know if that answers it from our point of view.
MR. BARNETT: I think the thing that comes closest to this is PKI, as far as a standard, as well as ETS work on PKIX, which are closely related. They don't specify the technologies to the extent necessary to guarantee interoperability. So what we end up doing is a lot of common understandings. There are standards that are being worked on with an ASTM E-31, ISO TC-215. We are trying to get to some common understanding of how to do this.
Kaiser has invested heavily in PKI, because we think this is the most cost effective approach, but there really is a lack of standards in the area that take care of everything, meet all the requirements.
One of the problems with this is, we get down to technology specific implementations. Biometrics for example are something that we are looking at, and we are very interested in it. That is only one method of authentication, something you have, such as a token, something you are, biometrics, and sometimes people have the category of something you do, such as handwriting analysis. These are all authentication approaches, and we need at least one for authentication and probably two, for strong authentication.
When you get to how you do that, we are getting into technologies, and that is an area I think we have to tread very carefully in. So PKI comes very close to being a comprehensive standard, even though X509 is a framework in the recommendation, it is not really a standard. It is pretty close to what we think is what the answer is going to be. But we are still dependent on common understandings with our peers and business partners and within our community of interest. So it is a problematic area.
MR. BEATSON: I wanted to address the front end of this process, which is essentially, you begin with a document, and you want to get a signature on that document. You then want to secure that document and you then want to transmit it to somebody securely.
The actual document management associated with getting the signature on there is available in numerous -- well, I won't say numerous, but certainly well used software packages, such as those offered by Adobe Acrobat and indeed, Microsoft Word. Now, most businesses, I am absolutely sure, use these software vehicles for their document generation and management.
So what the electronic signature industry is doing is making available to these well-used packages the capability of adding an electronic signature verified biometrically if you so desire, to that document. Thereafter, the digital signature part and the PKI part and the encryption part can be handed over to the digital signature people, who offer systems for that. So I'd say it is two parts.
MS. GUGEL: I have one comment on this. I want to provide a little background. The health care industry itself has a lot of custom legacy applications that are not enabled to accept digital certificates for authentication. That is one issue.
There are a lot of vendors out there creating new type of applications such as electronic patient record applications, that need to be PKI enabled, especially if we are going to mandate the use of digital signatures for the health care industry. So that requires the use of either a toolkit or some customized integration.
Some of that customized integration has been done by companies such as Silanis or Cybersign, because these companies have recognized the need for adding multiple signatures and counter signatures and document control with signature control throughout the whole process.
I consider those applications that are PKI enabled. There is a host of other applications out there in the industry that need to be PKI enabled or able to accept and recognize an X509 version three certificate for authentication.
So if we are going to mandate digital signatures, then there is a lot of work to be done in the industry for enabling the applications. But there are a lot of tools out there for them at their disposal. Baltimore RSA and some of the other vendors offer tools for developers to PKI enable their applications. There are some other niche companies out there that are going ahead and enabling the major applications like the ERP systems, and then you can buy these snap-in products, so that you have PKI enabled applications.
The main applications today that are readily enabled are pretty much the mail systems using S MIME web access control, web based access control to accept digital certificates. Most of the VPNs are out there, so you have extra-net solutions. Some of these industry specific applications, like a lot of the ERP systems, that have not been PKI enabled yet, they are looking at this technology and what HIPAA is going to say about it before they move forward.
I do want to make one comment about what Peter addressed. You said that there are not a lot of large-scale implementations of PKI in health care. One of those reasons is, there wasn't a driving force like HIPAA yet and a lot of them are waiting.
Some of our customers include the Australian Health Insurance Commission. It is a relatively new customer, maybe since June, so they are not in widespread use yet, but they are gearing up for very large implementation, since it is a national health care system, much larger than any one health insurance company in the U.S. So that will probably be our largest health care implementation of digital certificates.
As far as installed base, we have the two cases I mentioned earlier, ABN Ambro and the Australian Tax Office, have each over a million issued certificates, so we have some large scale proven PKI systems outside of the health care industry.
DR. BLAIR: First of all, in the tradition of the NCVHS, any time there is a testifier or a standard or a vendor where we have direct association for public disclosure, we wind up by indicating that. My good friend and my employer, Peter Waegeman, is one of the testifiers, so I wanted to indicate that.
Then I have a question for -- I think it is Ron. Ron, I think that you indicated that when you use PKI technology, it identifies the source, but not the individual. That left me a little bit confused, because I thought with the certificate process that it did identify the individual, maybe not directly, but at least -- I can't even say it is indirectly.
Anyway, could you please clarify for me what you meant when you said that?
MR. BEATSON: Yes, in fact, I did say that. Let me put this in the context of a particular situation that might occur. If you are sitting in a work station on an Internet and you generate a document and that document is then -- goes through the digital signature process and it goes to the other end, the only thing that that person at the other end knows is that the private key associated with that transaction was submitted at the source end.
Now, that private key typically is not entered by the individual at the work station. That private key typically resides somewhere on a work station or a server. So if you are sitting on an Internet, actual work station, conducting transactions, and walk away and leave your P.C. on, and somebody else could -- not at all likely, but could come and conduct a transaction at that work station. It would not be clear whether that transaction would have been conducted by you, the normal user at that work station, or not. That is the point I was getting to.
DR. BLAIR: If that is the case, then that is new information to me. Could I get comments from the other panel members, acknowledging whether that exposure is in fact correct?
DR. COHN: Maybe I'll just start out, since I practice clinical medicine. Ron, what you are saying is probably not an uncommon practice. I think if everyone tries to have computers turn off when somebody leaves the use of that computer, there is nothing that turns off every time you don't use a keystroke in two seconds or whatever. So obviously there is that exposure.
MR. BARNETT: As Rod points out, there is exposure within a digital signature structure or PKI. That is why it is important to identify and specify the procedures involved for your identification and authentication.
For example, I have a class one verisign certificate that I paid I think $9.95 for, and I just gave them my e-mail address and they sent me one back. How well does this identify who I am? Well, I paid for it, and it's a good credit card, anyway. On the other hand, I can download a certification authority toolkit from a particular large vendor of PKI products, and create my own certificate. So I can make up and put in just about anything I want.
The technology allows me to do this sort of thing. Where it is important to identify the procedures -- this is maintaining the ownership of the signature and those kinds of procedures, I think that is the area we need some regulations and some standards in. How do you identify a doctor? One of my standing jokes is, on the Internet, nobody knows you're a doc.
But the no authentication problem is very difficult, and we need to come up with some way in the regulation of the standards of trusting who is that person who owns that certificate, and how do you know they are controlling it properly, and how do you know they are not leaving the work station logged on all day so that anyone can use it. Those are some of the issues where it would be appropriate for us to identify the standards and the regulations.
DR. GELLMAN: I want to ask about this from a somewhat different angle. Let us assume somewhere down the road that we have some sort of full-scale PKI system with certificate authorities and registration authorities, whatever. I am looking at this from the angle of privacy consequences of all of this.
The first thing that makes me a little nervous is that the digital signature may in some way become effectively a universal identifier; you need to have this to do anything. The second thing I'm worried about is that the verification process, which a couple of people talked about, at least mentioned, creates an incredible surveillance system. As I go somewhere, I show my identification, which gets verified, and now whoever is doing the verification has basically an audit trail of my life. They know where I was, they know what I was doing and they know when I did it.
Does anyone want to comment on that? Has there been any thought given to some of the consequences of all of this information that may accumulate?
MR. WAEGEMAN: Yes, you're right, we are moving toward patient identification. However, from my point of view, and I consider myself as a patient advocate in the field of signatures, as you probably know, Bob, I have been very outspoken in that field, this is one way which seems to be a solution. It seems to be very acceptable that we have not -- all the arguments we have had in the past for universal patient identification systems, all of the negatives are falling by the wayside, and we have a positive way of identifying.
However, it would be wrong from my point of view to focus on that right now, because that is not a political issue, and it is the second step. The first step is to create a PKI for caregivers. This by itself provides much higher security from the point of confidentiality.
I agree with you, electronic health record systems today are not safe and not secure, and confidentiality is in a sad state. PKI will really make a difference. So the only way at this point where we can say we clearly can identify who is accessing information, who is originating information, who is taking responsibility for information.
DR. GELLMAN: But I am getting at what we are doing potentially. Don't leap to conclusions that this means that I don't think we should do it; I just want to have these issues discussed. We are creating potentially a new database that essentially surveils people as they move through the health care system or as this broadens in the economy, we have an entirely new entity here that has a tremendous amount of personal information on people, and it is something that never existed before.
There may be benefits to all this in terms of protecting the confidentiality of records. I am skeptical about that, but it is a possibility. I want to focus on this new thing that is getting created.
MR. BARNETT: One comment I would make about that is, I am hearing those same concerns. One approach which is somewhat similar to what is being done today is having more than one certificate.
For example, the certificate that identifies a person as a physician should probably not be the same one used to purchase things over the Internet. A list of people with M.D. after their name might be a very sellable item to certain junk mail lists.
I think we really need to separate out our identities, depending on our roles, to some extent. Surveillance within the medical community, it is a bad word, audit trails, are probably appropriate, especially with medical records. It might be a very good identities of you as a consumer versus you as a physician, and not have one certificate that is your universal identifier. That is one approach.
DR. COHN: How many certificates do you think the average individual would have to carry?
MR. BARNETT: I'm thinking at least a dozen. I'm trying to get the number as small as possible, because the other approach is, you have too many, and it is just as bad. So somewhere there is a happy medium between the maximum and minimum number of certificates necessary to do business over the Internet and electronically.
MR. WAEGEMAN: I currently have six different health cards. That means I am in six different databases for my personal identification. It may be with PKI that there are four or five. It will not be that there is probably one national or international authority. These authorities can be handled in a much better way than any open system of patient identification as we have been talking about.
But one point I wanted to make as we probably will come to that, I had not talked about my function as the chair of ANSE HISB, American National Standards Institute, Health Care informatics standards. We have identified that there are between 12 and 18 different approaches right now in the United States of creating PKIs. We have representatives here from three companies, I see another four or five, out of 15 or 18.
I just want to set the record straight that we may not even have the most active one in health care. We do not have a full representation here.
We are trying to coordinate, we are working on a voluntary basis of the major companies out there and also organizations such as Kaiser and Chime, and I am inviting of course anyone else to participate. But we are trying to come up with the issues and moderate and come to a mediated approach of one acceptable health care approach in that field.
We have to understand that yes, there are still some holes in PKI. It is a very complex issue. However, the longer we wait, the more it will hurt. I will be talking in the next panel what Canada and Australia and all those countries are doing.
DR. FRAWLEY: I just wanted to make a comment, because I think it is important just to reinforce what we heard this morning.
The first thing in terms of disclosure, I have to disclose that I was a member of the original E 31.20 subcommittee that developed the standard on E 1762.
DR. COHN: You have to give the name as well.
DR. FRAWLEY: Electronic Health Care Information. But I do want to follow up on a comment that Anne made, and I think it is important that we recognize this morning. Most of our clinical information systems in this country as Anne pointed out are legacy systems. Most of them would not support a digital signature application.
Probably more troubling to me right now is the fact that many of the products that are coming on to the market again would only support an electronic signature, and would not support a digital signature.
I just happened to look at a new product from my hospital two days ago, and we talked about HIPAA, we talked about electronic authentication, and basically this product would only support an electronic signature.
So I just want to bring that up, that unfortunately right now, most of the users in our health care delivery system in this country that are using some type of electronic signature would not meet any digital signature requirement under HIPAA.
The second thing I want to raise is many of the vendors that bring the products to the marketplace are really only bringing products that would provide for an electronic signature. I don't know how you would be able to transition from these products.
MS. GUGEL: That is why I brought it up. A couple of things. First, they are waiting to see what HIPAA does require, and they know they have two years, two or three, two at least.
There are a lot of toolkits out there, and Baltimore is one of the vendors that provides these toolkits. The toolkits -- since the RSA algorithm patent just expired, and toolkits are now, as of September 11 or 21, whatever the day of the expiration was, they are now more readily available worldwide at a much lower cost, and easy to purchase by vendors other than RSA and Baltimore.
Before the RSA algorithm expired, products were much higher cost. Now we have a huge amount of interest from vendors in all different industries who want to PKI enable their operations. They know they would like to, but before it might have been cost prohibitive. So now it is very low cost and very easy for them to purchase these toolkits, and we are getting a lot of interest in the health care industry as well. They want to enable their applications, so they will move in that direction if the requirements do require digital signatures.
MR. LAURE: If I may add a comment to that, most of the competitors that we deal with are electronic signature vendors. I would have to say that any of the ones that we compete against all incorporate digital signature technology into their products. Anybody who doesn't, we don't end up competing against them, because our customers would not buy such a product in the first place; it would be insufficient from the security point of view.
So I just wanted to add that as a comment.
DR. COHN: Kepa would like to finish with one final question, and then I think we will try to give everybody a break. We are very far behind time, but I think we're okay.
DR. ZUBELDIA: Thank you. Peter, with HISB trying to coordinate an international standard, all these PKI efforts to come out with one solution that we can adopt, I would like to ask the whole panel if they think -- what would be a time frame for coming up with a solution that we can adopt in this country, as a HIPAA standard for digital signatures, not just PKI, but looking at both PKI and electronic signatures. Is there such a thing as a solution that could be adopted? And what is the time frame we are looking at?
MS. GUGEL: I'd like to at least start on that. I believe that the solution is not just one technology, but a combination of technologies. Since three of us represent different vendors, of course we would like to sit here and say we can do that for you. But that is why I mentioned early in my testimony that the partner programs that we have are so important, because I really think that both technologies are important in signing documents and tracking the signature through the system.
PKI provides the trust for identification authentication of an individual through the digital certificate. But even my own company makes another product that tracks multiple signatures on forms, called Form Secure. So it is not one product, but it is a combination of more than one product.
MR. LAURE: I'd like to add to that. I agree with Anne, and I would add to that, if I look at the experience that we are actually involved in right now ourselves in the Department of Defense, where they have defined their own standard for PKI, and have implemented it -- I'm not sure that everybody is necessarily happy with it, but it has been done. It actually is quite usable and works with our product at this point.
The approach there is that we have implemented a PKI. What PKI gives you is managed certificates. In other words, everybody gets certificates that are controlled properly, so you all have your identifiers. Now what you need is PK enabled applications which allow you to use those certificates to sign whatever it is that you need to sign.
In the end, it boils down to adding support to all of these different applications to be able to use that kind of an identifier. So I think the key standard that really is the issue in the end is having -- if you are going to go with something like certificates or PKI, then you've got to define that and roll that out to people so that they have their digital I.D.s, and at the same time, you've got to encourage vendors to implement the applications to put the signing capability into it, and put it in a method that represents an acceptable way of signing.
What that boils down to is, go back to what a signature is. It captures a person's intent to authenticate the writing. That's it.
DR. ZUBELDIA: Time frame? Two years? Five years?
MR. LAURE: You could start that this year, if you wanted to. The applications are there, and PKI applications are definitely there as well. Baltimore I'm sure would be more than happy to come in and implement a pilot in a hospital or whatever to put PKI into place. But to say that it is going to roll out across the entire country, I don't know, probably 10 years. I think I have heard that it takes 10 years for a new certificate to apply itself across in a widespread kind of way. So if that is the case, then I think you could see the same thing from the point of view of health care. And of course, there is the fact that you are dealing with thousands of different corporations here in essence, as the marketplace goes.
MR. WAEGEMAN: I agree, the technology is there. We could do it today. Secondly, there are installations today happening in Chime in Connecticut. You will hear this afternoon. If you look internationally, the province of Quebec has it fully implemented, Finland has it fully implemented. In Australia, people have implemented it in and in three Asian countries.
One could say it is not quite ready, but let me compare to when HIPAA came out and we were struggling, what should be the messaging standard. There were holes. We needed implementation. In the same way we could say today, let's adopt PKI, and yes, in six months or in nine months, in the same way as what happened with HIPAA, we could have all the holes filled, because these are policies, these are issues of how to implement them.
The technology is out there, but it is a very complex infrastructure, where we really need some leadership in what can be done. But it is being done in other countries, because people realize the earlier we are doing it, the more we can save to the country and the more we can make systems confidential and secure.
MR. BARNETT: One of the issues here is to what level of detail are we going to specify. First of all, I think it is extremely important to start blocking out what we need to define, because that helps us converge. If we just let everything go until we have all decided what the answer is, it is going to be too late, and we will have hundreds and maybe thousands of different kinds of implementations.
The first level of digital signatures, I think that is where it is today. IEEE Standard 1363 and FIPS 186 are well defined. They list algorithms that are technologically neutral. The next level down perhaps might be PKI. That is also pretty well defined and fairly mature. It is a well known technology. There is a framework. I think we could go with that if we say for infrastructure.
The third level down, health care PKI, is still up in the air to an extent. Kaiser is implementing a PKI, Chime implemented a PKI, several standards committee which I am a part of are working on what are the details, what needs to be in a health care PKI certificate, for example.
Those are some issues we are still working on, but we are trying to converge very quickly, because we all have a business need to get it down as soon as possible so we don't have to redo the technology.
MR. BEATSON: I'm just going to look at the front end of this again, and say that the actual identification of the individual, there is an emerging standard through the bio api consortium, which again is being supported by NIST and is government supported. I suspect that any biometrics which are used in this process or in the other process going forward will eventually adhere to that standard.
DR. COHN: Jeff, do you have a comment or a question? Because if you have a question, we are going to need to adjourn this panel.
DR. BLAIR: Okay.
DR. COHN: I really want to thank the panelists. It has been a great panel. We are going to adjourn for 15 minutes.
(Brief recess.)
DR. COHN: I'd like to welcome our second panel to talk about the business case for the electronic or digital signature. Jean Naricisi, would you like to lead off?
MS. NARICISI: My name is Jean Naricisi. I am the Director of the Office of Electronic Medical Systems for the American Medical Association. It is my pleasure to appear today on behalf of the AMA before your subcommittee, and I'd like to thank you for this opportunity to testify.
The growth of online health care services could be dramatic in the next few years, as physicians, hospitals, pharmacists, insurance companies and others move to streamline their actions with each other and with consumers. Effective and affordable user authentication will be a key enabler of this business growth, providing the foundation for high level privacy and confidentiality that are essential in the health care industry.
The authentication in the electronic signature process must be simple, quick and reliable, and be flexible enough to authenticate users across a complex network of health care websites. However, the use of computers as well as the use of the Internet by physicians has not yet caught up with that of the other industries.
Physicians are reluctant to jump online, and rightly so. Despite the wonders of the Web, its wide accessibility has posed security challenges, especially when it comes to private medical records.
As background information, I'd like to share with you the following findings of the AMA study. In 1997, the AMA conducted a large scale benchmark survey of physicians in the U.S. to determine the penetration of web usage in the physician population. This study sought to identify physicians' patterns and habits in Worldwide Web usage. In 1999, the AMA conducted a framework survey of physicians to determine changes in web usage.
For the purpose of both studies, a web user is defined as someone who uses the web him or herself or for personal or professional purposes.
Since the benchmark study in '97, the proportion of all physicians who have access to a computer remain virtually unchanged, at 43 percent versus 41 percent in '99. This means that 59 percent of all physicians reported they do not use a computer. Of those that do use a computer, the proportion with access to the web however nearly doubled from 20 percent in '97 to 37 percent in '99. Of the web users, 27 percent of physicians indicate that they had a website in '99, which is up from 17 percent in '97.
The '99 study indicated that the majority of the physician web users consider the web most useful as a communication tool. Other uses include accessing medical information, news and information resource, as well as a drug information resource.
As for security, the '99 study indicated that 67 percent of physicians believed it was risky to give their credit card numbers out over the web for purchases, and 83 percent indicated they have concerns about data security and confidentiality of medical records on the web.
I'd like to provide the following information in response to your questions. What sort of health applications to electronic signatures enable? The AMA is working with the Intel Corporation to deploy a new form of electronic identification called the ANE Internet I.D. It will protect physician and patient privacy and confidentiality when using the Internet to send and receive medical information.
Intel introduced Intel Authentication Services, AIS, which develops and operates authentication services for associations, organizations and any health sites that want to offer branded e-health digital certificates to their users. The AMA entered an I.D. to uniquely identify physicians over the Internet, providing a reliable authentication technique with passwords for secure Internet transactions. The AMA I.D. functions online the same way drier's license, passports or other trusted documents.
(Recording interrupted.)
-- the validity as traditional paper signatures, and explicitly forbids the denial of an electronic agreement simply because it is not in writing. The law also forbids in the state statute a regulation that limits, modifies or supersedes e-signing in a manner that would discriminate for or against a particular technology.
However, e-sign does not supersede the state laws in the area of the retention of medical records. The retention of medical records in some states may become an obstacle for physicians when using electronic signatures, because some states require that medical records be stored for a very long time, for instance, after death or even until a child turns 18. This would require paper or microfilm storage.
In addition, the e-sign law has very low security standards, and as a result, it appears that electronic signatures could be repudiated easily.
How does the computer information transactions act impact? This law that is intended to govern all contracts involving computer software and information that can be obtained electronically. It also stretches easily to cover computers, printers and other computer peripherals. This proposed law grants no intellectual property rights to software and information publishers beyond those of the United States copyright and patent laws. It would make it almost impossible to hold vendors of defective products accountable for defects and misrepresentations. This could put more liability on physicians, which could create even another obstacle to the use of electronic signatures.
Are health care requirements for signatures different than for other industries? Medical information is private, confidential and it is not replaceable. It is not the same as credit card information. Protecting confidentiality and privacy is imperative to insuring the strength of the consumer trust in a changing technological health care environment. Electric communications are drastically changing how patient information is stored and transmitted. But what hasn't changed is the physician's responsibility to maintain the confidentiality of patient records, and electronic patient records are no different from paper medical records, in that they contain privileged information that may not be divulged without permission from the patient.
The AMA Internet I.D. comes at a time when there is a growing awareness of the threat to breaches of medical privacy, confidentiality and security of the medical record in the digital age. In addition, levels of security, reliability and quality of service are necessary for health status to use the Internet need to go way beyond those needed for typical e-commerce.
Do you think there are digital solutions in other industries that can be used for health care. Authentication technologies are evolving rapidly to meet new business requirements. Like other online businesses, health care service providers will need to adapt their content and security procedures to address the requirements of new access devices such as PDAs, cell phones and other Intel devices. In addition, many PCs and other digital equipment will soon come equipped with fingerprint scanners, eye scanners and other biometric authentication systems. The AMA Internet I.D. and other Intel IAS infrastructure are designed to be extensible, so they can smoothly accommodate these in the future.
AMA and Intel are currently working to integrate a few new features in Internet I.D, which includes delegation. This service enables professionals to delegate staff members to act in their behalf in authenticated online transactions. In addition, they are working on enhanced fraud detection. Fraud management enhancements are likely to include automated monitoring of activity logs with flagging of potentially fraudulent activities.
As online health care evolves, AMA and Intel are committed to providing a high level of authentication integrity that will be combined with procedures and tools to make it easy for businesses to deploy and administer their authentication services, as well as make it increasingly simple for end users to obtain secure access to the information and services they need.
Thank you.
DR. COHN: Thank you very much. Sherry Neuman.
MS. NEUMAN: Good morning. I'm Sherry Neuman. I am going to be speaking to you from the perspective of a health care provider. My entire career has been spent in hospital-based practice with specialties in drug use evaluation and investigational studies.
Recently, I joined a small startup company in Silicon Valley that has produced the hand-held technology on Palm Pilots or pocket PC devices for physicians to write prescriptions, and then electronically transmit those prescriptions to pharmacies. In addition, we are responsible for providing the physician with enough information to prevent harm to the patient. For instance, if the newly prescribed drug has a potential for a drug interaction or a duplication of therapy or a drug disease contraindication, we want to be able to provide that information at the point of care, so that that can be averted before it happens.
What that means is a lot of personally identifiable information has to be provided amongst providers of health care. So the security and protection of that patient information is very, very important. The transmission of that information from provider to provider to provider is also very important, and we have to make sure that the person who is receiving the information that we are providing is the person who is authorized to get that information, and also, that person who is sending the information back through our server is the person we think it is.
This is a very, very interesting time for us. Because of my clinical experience and a prior lifetime, where I was fortunate enough to develop the system for online outpatient DUR for Medicaid agencies -- and I did that for 20 states -- I am very sensitive to patients' privacy, so I am also the chief privacy officer as required by HIPAA for our companies. So those two hats make this a very interesting and exciting time, and I appreciate the opportunity to be here.
The health care applications that we see most important where standards could be a boom to not only the economics but patient care, are physician to pharmacy transactions, certainly getting the prescription to the pharmacy in a clean legible way that doesn't have to be manually entered will make a difference in the reduction of medication errors. There are also the reversal transactions that go back from the pharmacy to the physician, where the pharmacist may be asking for a refill request, or maybe requesting a change in the original prescription due to formulaic considerations or additional patient information such as a new lab that the pharmacist is aware of when they are doing anti-coagulant screening. They want to be able to communicate that back to the physician in order to get a change in the prescription.
The physician-pharmacy and pharmacy-physician transactions are enhanced by the National Council for Prescription Drug program standards. If you think about the health care industry, the pharmacy is certainly the most computerized of any of the facets of health care. The early '80s saw the universal claim form, where everything was done on paper. Mostly patients had to collect all of their receipts for their health care and send those in individually into their health care insurer or payor. Then in the mid-80s, the NCPDP developed the telecomm standard version 1.0, which was simply a non-interactive, one-way transaction. Pharmacists could online send a transaction to a payor, a processor or a PDM and get notification that they probably are going to get paid for that claim. It was not a two-way conversation, but you had at least an assurance that the payor did receive the transaction.
We are up now to version five at NCPDP, where clinical information is being sent back and forth between pharmacies and processors and PDMs. Again, now we need to know for certain that the patient whose information is being transmitted, there is an authority to do that by the pharmacist sending information or the PDM receiving it. So the standards for electronic signatures or authentication of the sender are becoming absolutely essential.
I think the requirements that need to be met -- and we have all heard this throughout the morning, but they have to be -- the signatures have to be unique and identifiable to only one person. It was mentioned this morning that if your computer work station is left unattended and someone else sits down at your station, they are you, and anything that is done then is going out over your name. So we have to have individual identification of the user of this certificate and then an audit trail.
To satisfy those requirements, what we are seeing is that vendors of certification, vendors of these registrations and certificates are beginning to take risk for their information. Again, a standard would certainly help them, but that is a big step forward. They are actually saying we will identify this person and guarantee that they are who they are. Companies like ours, who absolutely do not want to be in the business of credentialing or verifying credentials then can rely on companies like Medipass, which is an *arm of the California Medical Association. There are others as well, VeriSign for the hardware, so these companies are taking the risk for their programs.
What we do at Iscribe is twofold. We have SSL and encryption for any data that is transported over any kind of wireless or even wired connections. Also, the VPN or virtual private network which protects the data security that we receive.
Then the other part of that is what we are calling the electronic or digital signature, where the handheld devices actually capture prescribers' signatures and can print that on prescriptions, so that this is now a fully complete and legal document, even if the prescription is transmitted electronically, the patient then has a legal receipt that they can take with them. This is I think important for reducing medication errors, so the patient now has a completely legible receipt to compare with their prescription vial.
I could not over-emphasize the importance of standards in the health care industry. Again, we can go back to the pharmacy industry where the standard is what has allowed pharmacy to become so well automated and so efficient. The claims transactions -- there are close to four billion prescriptions filled in this country -- I guess that is in the next two years; right now it is 2.83 billion prescriptions in this country that are being sent back and forth electronically that are being sent to payors and processors electronically, so the standard for that could take the page out of the book from the pharmacy community that is very well organized and computerized.
Another part of the standard setting came from the federal government with Over 90, where outpatient automated drug use review was mandated for all Medicaid prescriptions. Every state board or pharmacy following that required pharmacists to do the same kinds of surveillance for prescription errors that were happening for Medicaid patients, because you can't have two standards of care. So this would even bleed over into the question about what role can the government play.
We would not have the kind of evaluation and surveillance going on in prescriptions if Over 90 had not said we will have outpatient drug use review, pharmacies will provide both prospective and retrospective review of prescriptions as they are being filled and then as an audit after they are being filled.
What we want to do though with standards like Over 90 is move this closer to the point of care. When outpatient pharmacy drug use review happens, it occurs after the prescription has been written, maybe several days after the prescription has been written by the physician, because patients don't necessarily show up at the pharmacy immediately after they see their health care provider.
So what we want to do is be able to move this closer to the patient, and that is to provide this information at the point of care in the exam room. So if there is an anomaly or what we think of as therapeutic misadventures, that can be corrected at the time that the patient and the physician are still together.
I think the government has an absolutely wonderful opportunity and a huge role in setting the standard for electronic signatures, for electronic transactions.
One of the things that this will do is -- I just concluded a review of all 50 state boards of pharmacy, so that we know that the prescriptions being created by the electronic prescribing application meet those rules and regulations. I was shocked, disappointed, to find out that there are 50 different pharmacy prescription blanks, because we have 50 states. If we had 51, there would be 51 pharmacy blanks. That makes no sense at all. It is a setup for error. It means that you cannot standardize a very routine rudimentary thing. A prescription is always the name of a drug, a strength, a quantity, a direction for use, and number of refills. There is no reason for that to be placed in different places on different prescription blanks, based on if you practice in Idaho or Washington, D.C.
So again, the government, by saying here is what the standard is for an electronic transaction, here is what the standard is for an electronic signature, will give permission to the boards of pharmacy to follow that standard. Many of the boards are silent, because this is a brand new thing. So they have no rule at all. They don't want to be not in compliance with federal guidelines, so they are holding off and doing nothing. That means that no transaction can be sent electronically in many, many states.
I have to tell you, in my own state of California, printed prescriptions for controlled substances are not legal. I guess we would much rather have an allegedly handwritten prescription for a schedule 3 drug than we would have it printed and signed by the physician. So the kinds of things that we need to have happen by the government are giving the boards permission to do what they would really like to do, but their books are many years old, the laws on their books are old, and they have not had the authority to change those laws.
How will e-sign impact what we are doing in the transfer of prescription information or health care information amongst providers. I think it is absolutely the first step. It now says that there is an authority to make -- and validity to make electronic transactions, electronic signatures a value, a reliable and credible, legal -- and that is the first step, to take that over into health care and start moving these transactions as they should be.
We have talked about, are health care requirements different from other industries. This goes back to yes, but my patients are sicker. Absolutely, they are different in health care. Not only do we need to know who the person is, but we need to know their credentials. I think that was touched on this morning, that if you have a prescriber who may be a nurse practitioner or an advanced physician's assistant or a nurse midwife who is authorized to prescribe in one state, that is not necessarily true in other states. So the electronic signatures in health care have to carry much more than, yes, I have a valid license. It is, I have a valid license and I am valid to use that license in this state.
So we think absolutely, health care is different. That is why we need to spend so much time to make sure that our standards that we come up with and the protocols that we come up with meet the needs of all the states.
The last question is, are there additional signatures in other industries that could be used in health care. Dave Barnett this morning felt that yes, there is a carryover. I think that health care information is much more sensitive and much more vulnerable to abuse, however, than other types of information. So there may be a carryover from other standards. I think they probably will need to be more restrictive, because of the fear people have of their health care information being used in ways that would be detrimental to them.
I appreciate the opportunity to present before you this morning, and I will provide a hard copy of the comments.
DR. COHN: Thank you very much. Peter Waegeman.
MR. WAEGEMAN: In 1991, the Institute of Medicine did a study that the creation of computer based patient records system is a necessity for health care. This vision has been widely accepted in the last 10 years. However, it cannot be recognized without a security infrastructure.
You have to realize that this is part of 10 years, and in some cases, up to 30 years of efforts, and spending money and investments. We have over 95 percent of providers who still have to keep paper records parallel to their computer records. The costs can only be estimated for waste in personnel and resources. We have no clear figures, but it is a sad state of affairs.
One issue which is for the business case is that with the creation of a security infrastructure which creates higher confidentiality, higher security than anything we have at this point, than both paper based systems or computer based systems. This is the only way to go.
So it is really important to understand that for the vision of electronic health records, for the vision of better confidentiality, better security in our health care system, we must think and implement information security infrastructure which is best expressed by PKI.
What we have to realize in all of this is that the business case is clearly -- that by having such a system we can get rid of the parallel paper, which means eliminating the printing of transcribed information. It also means eliminating the time wasted, with physicians having to go and sign physically in hospitals and clinics incomplete records, eliminate physician time for finding information, eliminating physician time to all the efforts of chart assembly, all the efforts of records storage and retrieval. This is just enormous. It is hard to estimate what is the number of looking for information and for retrieval feed and the storage feed and so on. The savings can be substantial in that field.
Then finally, eliminate all the costs associated with records transportation. Many hospitals with clinics and so on have to have shuttle vans to send paper records around. The number office is parallel to the computer systems we have at this point.
I have seen studies which have shown that the savings could be as high as $135 billion a year. We have no accepted general study, so I will even go by the lowest figure I have ever seen, which is $50 billion a year. I assume from another study I have sen that the cost of implementing PKI nationwide would be from $45 to $52 billion. It is a one-time cost. I believe strongly that PKI is going to save the country and the health care system, much more than what we are currently trying to save for HIPAA.
So this is number one.
The main point however is that we have a wide range of state laws, of situations which need to be corrected in order to create a national and international health care system. You have in your appendix a printout from the Chicago law firm of McBride, Bacon and Coales, who seem to follow the state laws.
If you just look at those, almost every state is limited to IRS records or it is limited to communication between financial institution and customer, always limited to one area. We need in the same way some kind of legislation and standards for a national system which overrides or is applicable for all of the states, and enables us to exchange information in a secure and safe way that we know who is authorized to see and deal with the information, what we have just heard about prescriptions, and general information exchange. This is priority from my point of view.
So to make my recommendation short, if you look at what else is going on in the world, we have eight countries which are pretty far advanced. Australia is moving along in some areas. In one or two areas it has pilot projects which are well established. When we look at the U.S., we have Chime and we have Kaiser and we have some others working along very fast. There are some companies not represented here who are hoping to have large numbers of certificates issued by the beginning of next year.
We have to realize that in Canada, Prince Edward Island, for instance, has a well established system. It is small, but people have been doing that. In Germany at a recent conference, the representative from the Ministry of Health said that they consider themselves five years ahead of the United States in their security efforts through having established a PKI.
We are really behind if you look at what is going on in many of those countries. Why is that? The main reason is that the public in the past have heard the message that, well, whether it is in HIPAA or not is not clear, and people should wait before they go along in that field. We really need a clear resolution that PKI is the only way to create confidentiality, to create security, to save money and to implement the vision of electronic health records.
This can only be done by on the one hand having the current standards as a basis for it. The standards of ASTM which are recognized internationally are particularly for health care, in addition to all the standards we have heard from different industries, which are base standards.
What we need at this point are four points. One is that the electronic and digital signatures should be included in the NPRM. Second is that the NCHS and HHS should take a leadership role in promoting PKI and its implementation in health care. The third one is that the ASTM E31 standards and other standards from electronic commerce should be recognized as the basis for implementing PKI. Yes, there are still some holes there, but as I mentioned earlier on when we started out with financial transactions, there were some holes too, which can be filled quickly. What we need is some leadership in that field. The final one is that NCVHS should urge Congress to come up for health care with specific legislation which overrides state legislation, goes into credentialing and provides the basis for future identification for future PKI and health care systems in general.
Thank you very much.
DR. COHN: Thank you very much. Benjamin Wright.
MR. WRIGHT: Thank you very much. I am an attorney from Dallas and co-author of a book called Electronic Commerce. I work for a wide variety of clients, the Mississippi Secretary of State, a committee advising the country of Indonesia on how to revise its laws to comply with electronic commerce, a wide number of vendors of different kinds of products in PKI, digital signatures, biometric signatures.
I have the privilege of traveling a great deal around the world, talking to groups and companies and governments about how are they using electronic signatures, what do their laws say, what should the laws say. My impression from this good deal of study and travel is that the subject of electronic signatures is a lot like the big elephant that all the blind men come and touch, and every blind person has a different perspective on what this electronic signature thing is supposed to do, what technology we need, what the procedures should be. I am just one of those blind men, not fully understanding the entire dimensions of the beast.
In light of that, I think that an organization like this that is looking to provide guidelines or standards or something to the health care industry needs to appreciate the true fluidity of the industry and the technology.
The technologies are not all set. They are not written in stone in a particular place. What we have really is a very dynamic collection of vendors who are all coming up with their particular idea, their particular approaches, and more power to them. We will see more vendors. We will see more inventions. We will see more patents in this area. We will see much more development. We will see more development in the field of PKI, we will see more development in the field of biometrics. We will see other creative ideas that have not been mentioned yet in the presentations I have heard this morning.
When you are thinking about establishing standards in the health care field, I am reminded of how extremely large and diverse the health care industry is. There is such a wide range of transactions that occur within a health care environment, from contracts to consents of patient, to authorizations by doctors, notifications by administrators, where they send information to a payor or whatnot. There is such a wide range of transactions that I am very humbled by that, and I will be very loathe to write very stringent regulations or standards or guidelines in light of the tremendous diversity and the tremendous change that is taking place and that will take place in the signature technology field.
I therefore tend to feel more that an organization like this should be thinking less about setting standards and more thinking in terms of education, in providing leadership so people can learn about the technologies, see some pilot projects play out, and learn what the ramifications of those pilot projects might be. But today, I would be very cautious about writing some kind of a standard that sets in any kind of solid way what technology needs to be used, what business model needs to be adopted. We are all in such a very, very early period in the use of electronic signatures, that any kind of establishment of standards runs the risk of locking the industry into something that is not going to make sense in a couple of years.
I would distinguish something that I have not heard distinguished much in the presentations so far this morning, between the requirements for a legal signature, where there is actually a law that says, I need a legal signature, where for example the doctor shall sign the prescription. There is where you need to be focusing on what do I need to get for a legal signature, what are the legal needs. I would distinguish that from security.
There are a lot of places where we may well need security. Security is really important, but the law doesn't necessarily say thou shalt have a legal signature. Therefore, there is a lot of ways where for example something that is called a digital signature might work very well as a security device, but you don't need to be wrapped up in the question about whether it is legal.
Conversely, there might be places where you need a legal signature for one purpose or another, but to say the signature per se has to carry a tremendous amount of security itself is not necessarily true. It depends on what the law means, it depends on what the situation might be.
To give you a sense for the breadth of technologies out there, I personally think that we will see more in the way of what is generally understood as biometric types of signing devices, even though it may not always involve biometrics.
One particular type that you don't see very much today, but I anticipate will be important in the next couple of years, would be voice signatures. An example of a voice signature I have here on my laptop. I think the microphone should pick this up.
RECORDED VOICE: I, Ben Wright, hereby sign the insurance application.
MR. WRIGHT: I see great potential for voice types of signatures into the future. One of the reasons I see such potential for voice signatures and other signatures of that nature is that microphones are becoming ubiquitous in our society today. I am carrying a microphone here in my pocket as I pick up a cell phone. It is becoming very common that people have access to telephones of all different sorts.
Computers are coming to have microphones attached to them. The kind of hardware necessary to capture a voice signature doesn't involve any kind of moving device. I don't have to pick up a pen to write my name, I don't have to have a smart card to insert into a computer. I don't need a personal identification number or a password that I can forget.
But that is just an example of yet another kind of technology that we don't hear a lot about today. In fact, I don't know of a single vendor who is particularly trying to sell a voice signature, but I anticipate we will see more and more of this as bandwidth over the Internet becomes greater and the ability to send voice files from one Internet location to another becomes less expensive.
Another idea that I am seeing happening is the idea of using notary publics. Mailboxes Et Cetera for example is rolling out a system where -- Mailboxes Et Cetera has some 3,000 locations around the United States. They have a notary public in every one of those locations. The basic idea is that if someone needs to sign a document, they don't have to go get a certificate from a certification, they don't have to go get a private key or a password or a PIN number. They might show up at a local organization where there is a notary public, and that could be someone in a hospital, or it could be at Mailboxes Et Cetera, or it could be in a number of different places. They show up for a moment and sign these using any number of different devices such as voice and written. They might type their name, they might do any number of things as the individual who is consenting to care or something like that. Then the notary might come along and confirm identity by looking at a driver's license, and then secure the transaction with public key infrastructure with a private key. So you don't have to worry about distributing private keys or certificates to millions of Americans; you focus on people who are professionals and trained in that type of thing, such as a notary public.
So in summary, I wish to interject the degree to which there is going to be innovation, and make sure that as this group writes anything in terms of standards, that you leave a very broad road available for innovation, recognizing that public key infrastructure for example is a very strong technology, but it can be used in so many different ways beyond the classic idea that you give someone a certificate and you give them a private key. Private key infrastructure can not necessarily confirm the identity of a person, but it might confirm the location of a signing device, it might confirm the location and the strength of a microphone that captures a voice. It might confirm a location and authority of a notary public, any number of different things.
So be very cautious about assuming that any particular technology such as public key infrastructure works in any particular way.
Thank you.
DR. COHN: Thank you very much. Questions from the committee? Kepa, would you like to start?
DR. ZUBELDIA: Thanks to everybody on the panel. You have different perspectives. I think we are looking for a business case for digital signatures. I don't see a voice for the business case, I see a business case for signatures in securing or signing prescriptions, and part of the maker or record. But before Peter jumps through the roof, I will say that the business case is for the electronic medical record, of which the signature is a component, which is the ability to sign it. But the savings is in the electronic medical record, like you saw in your previous panel, there was a business case for Microsoft automating their purchase orders. That is an EDI business case, the fact that it is signed is part of it, but the main thing is the EDI part.
I think in this case, the electronic medical record is a strong business case, and signatures is part of it. Maybe prescriptions has a more compelling business case.
But I have a question that I would like to ask, and maybe Ben Wright may have some ideas on this. HIPAA has a mechanism to set a standard and periodically change or replace the standard with a new standard. You are saying that we should not be adopting a standard that locks the technology in.
We have heard in the previous panel that maybe we should adopt a standard that forces the vendors to come to an agreement to implement whatever it is that we have adopted. So if HIPAA adopts a standard, the vendors will do it, whatever that happens to be.
Is there a compromise here, where HIPAA could adopt a standard and then as the technology evolves, adopt other standards? Or would we be painting ourselves in a corner if we do that?
MR. WRIGHT: I'd be very concerned about painting yourself into a corner, and taking industry down some trail that a vendor or a particular interest group might lead you to want to take at a time when we have such diversity among technologies and so much innovation.
I would tend to favor more the setting of goals rather than saying thou shalt write this kind of -- use this kind of algorithm, you shall have a ticket authority that does this, this and this and so on. Even the concept of a certification authority is an untested business model. When I say untested, I mean this PKI stuff is for example not all that well played out. We're not seeing lawsuits. Show me an example of a digital signature that has been tested in court. Show me an example of significant ongoing transactions that have been conducted with one particular kind of technology or another, where we can learn how did the liability shake out, how did we prove any particular thing, what were the real results of those technologies.
I am all in favor of industry working with these technologies. I am a big proponent of the advancement of technology. I don't have a particular agenda. I work for PKI companies, I work for biometric companies, and I work for a variety of vendors. I just think once you start down that path of writing some technical kinds of standards, you will -- I predict you will look back and you're going to say, boy, that was a mess, because we have now committed so much of the industry to buy a particular kind of technology that is not going to make sense two or three years from now.
MR. WAEGEMAN: Two quick comments. First of all, I couldn't resist to make clear in regard to the business case, if we say we want to keep paper records forever parallel to a computer system, then yes, there is no business case there. But whether it is electronic health records or any way to move a health care system into a more efficient system of the 21st century, PKI is part of it, and PKI is a business case for it.
The second point, I just want to make clear, because we discussed in the last panel, what Ben is proposing is an electronic signature. There is no clear indication where someone else tried to fake my voice or whether it is really his voice which is on there. We have said in ASTM E31 that maybe as an interim process it is acceptable; it is not ultimately acceptable.
The point that we say it hasn't been tested yet is really the case, who would move their hospital records to a computer system as long as the legal counsel says, don't do it. So it is not a question of testing it, it is -- the reality is, when is Kaiser Permanente going to get rid of all of our paper records and save hundreds of millions. That really is the test.
MR. WRIGHT: Just to clarify, you are interpreting what I had to say. I'm not saying that only voice -- I'm not saying that we shouldn't use PKI or digital signatures. I am saying that a full range of technologies are available out there.
DR. COHN: Peter, if you could do us a favor. I am struck by your business case issues and the cost savings. Could you provide the subcommittee some references upon which that is based? I think that would be really helpful. Thank you.
MS. NEUMAN: I wanted to make the same comment about cost savings and efficiencies. I apologize if I wasn't clear. What I was saying with the physician to pharmacist and pharmacist to physician transaction is definitely the business case for moving information electronically. When a physician can write a prescription, sign it digitally and electronically and transmit that to the pharmacy, there is a tremendous amount of economic efficiency as well as reducing the administrative burden that goes with paper records.
There is a particular efficiency at the pharmacy side, where these transactions then actually populate a screen, based on the script standard, the physician to pharmacist transaction standard. So there is no more manual entry. So certainly the business case for reducing medication errors is there.
When you think about other transaction types, physician to lab, lab to physician, the efficiencies are definitely there, and you have to have some kind of authentication that the right person is requesting that lab, and the right person is receiving the results of that lab. We think about asking for a prior authorization for additional health services through electronic transactions rather than a phone call that says, please call this 800 number to get a second opinion, or to get authorization for this prescription medication, it is not on the formula. It is again a business case for doing this electronically and for being able to authenticate who is doing it.
Charge capture is another one, where there are millions and millions of dollars lost in the health care system probably daily, but at least every year, where professional services are not being captured and charged for, because as you swing through the hospital and you do things, that is not easy to remember and track and write down. With electronic transactions, you can keep track of that on a Palm Pilot and then sending that off electronically to the payor, so again a business case from an economic standpoint.
Dictation and transcription is another area that consumes a tremendous amount of resources of physicians that can be automated, as long as it can be certified and authenticated.
So I think there is a very strong economic and patient care business case for electronic transactions which to me can't exist without electronic signatures that are verifiable.
MS. NARICISI: I would just like to comment on Kepa's question regarding standards. I don't think you should focus on technical specifications. We know that those change; technology is changing too quickly.
But I think you should spend some time in looking at this whole policy area. We have talked a little about interoperability, that it is not there. Maybe you can focus on standardizing some types of policies that could apply across. Looking at this area of malpractice on the Internet, what are the risks and the liabilities. I don't think anybody has really explored that whole area.
So there are other ways that you can apply a standard which wouldn't have to be in a technical specification.
DR. FRAWLEY: Any of the transactions requiring electronic signatures, I think it is important that we have to keep at the forefront that now the transactions would require an electronic signature.
I think one of the struggles that we have right now, if you look at the compendium that Peter provided us, we have a couple of problems. Most of the state statutes and regulations don't recognize an electronic medical record. I happen to work in a hospital that has an imaging system. I am keeping records on paper and I am keeping them on an imaging system, because it is not clear if we destroyed our paper records whether our imaged records would meet the standard for admissibility in a court of law, if we needed to present those records as evidence.
The other thing, if you look at most of the state statutes and regulations, very few of them apply to electronic records that are out there, very few states. So again, we are back to the problem where we have a lack of uniformity across the 50 states on what is an electronic medical record, or what would be the requirements for an electronic signature.
Then I think Jean raised a very good point. Probably the biggest albatross that we face is the record retention statutes, which are all over the place. AHIMA had published a practice brief. It is available on the Internet, but it is all over the place in terms of what the retention periods are for different types of records. That is problematic.
When you are looking at this whole area you have to in terms of your business case look at all these different issues. I am sitting here thinking, we are struggling with this, and yet we have these transactions that don't even require a signature.
I think the point that many of our panelists raised in the first panel and the second panel is that the technology is moving fast, and we have got to be very careful that we are technology neutral, and go back to some of the guidelines issues, which is I think where we need to focus.
DR. COHN: A question I was going to ask Benjamin. You have railed against premature direction on standards, but do you mean standards or do you mean standards that specify a technology? If the standard were technology neutral, would that address your concerns?
MR. WRIGHT: I guess so. I guess it starts getting into definitions of what is a technology neutral effort. Someone said that you can have a technology neutral standard that is based on public key algorithms. Well, the public key algorithm itself is a technology.
So I tend to think more in terms of goals, more general goals, like you want to achieve a reasonable level of confirmation as to the identity of the signer, saying it that way, rather than saying thou shalt have a certificate or a certification authority or a public key algorithm or a biometric or something like that. So I tend to be on the general side of the spectrum there.
I do appreciate the need for trying to establish uniformity across the industry. I would suggest, not having spent a lot of time looking at this, but I would suggest looking more at particular transactions rather than the whole range of the industry. You might find particular transactions where you would want to achieve some uniformity. Then maybe you might get more specific on what is going to happen there for purposes simply of uniformity in that kind of a transaction.
DR. FITZMAURICE: First, I want to say that I am remarkably impressed by both panels today. I have learned a lot, and they have a lot of depth in what they mean and what they have presented.
Some of the thoughts that are gelling around come to some of that background that they have given me. I want to pick up on some of what Jean said, what Kathleen added, what Simon synthesized a little bit.
When we did the security standard, we didn't say you've got to have a guard dog in front of the door. We said you've got to assess your risks, and here are some categories of risks, and you have to develop policies and ways to address these risks. If you do that, you're in good shape.
I am wondering, particularly by what Simon said, if the same kind of approach would be helpful for electronic signatures -- not to say that you've got to use PKI, you've got to use this or that, but to say you have to assess your needs, and you have to adopt mechanisms and policies that give you such things as the degree of authentication, integrity, non-repudiation, that you need for the particular transaction. Rather than nailing down exactly with what probability you have to be certain, we ask you to assess that probability for your own purposes, and adopt your policies, adopt the technology that lets you conduct business and clinical affairs with which you are comfortable, your patients are comfortable, and your business associates or partners are comfortable.
If we do that, is that a step forward, giving a larger framework upon which technology can shoot for?
Secondly, the question would be, are there sufficient categories, sufficient attributes or characteristics that an electronic/digital signature should have that we couldn't afford with a standard under HIPAA? Anybody?
MS. NARICISI: I'll attempt to do that. I think that would be the right direction to move into, like you did with the security, put it out there in a kind of a model more on the policy level than a tech specification.
As far as trying to maybe even look at what are some of the specific elements or characteristics that should identify or authenticate a user at a certain end, maybe not getting real detailed, but specifying like you did for instance in your NPI kind of thing, I think that would be the right way to go.
I also believe that maybe with these authentication techniques, then maybe that would satisfy your NPI that you are trying to strive for.
MR. WRIGHT: I would agree with the approach that is suggested. Then what is appropriate from government nationwide is education, in the sense of dog and pony shows, to go around the country and show, here are some examples of how you do that. It is not necessarily that we are telling you that you have to do it this way, and regulations that say, though shalt have a private key that is so many bits long and things like that. But you can start giving people examples.
My hope would be that as electronic signatures become more ubiquitous in society as a whole, that it will through the next five years or so become more clear to people in the health care industry as well as elsewhere what is the appropriate kind of technology for particular kinds of transactions, so that you will see some uniformity come up, but it won't be a top down type of uniformity. It is more of a grass roots -- meaning different industries start to feel comfortable using one kind of technology or another.
MR. WAEGEMAN: My fear is that if we take this kind of an approach, that we will not create a climate where the average hospital will say, we can get rid of our paper records.
The moment we let it go in the way it is going right now, many hospitals and clinics and doctor's offices, and any practitioner's office, as they move to computerization and are buying some kind of electronic signature system, and in some cases worse than that, this will not allow them to go the step to a digital system which allows communication, allows better security and so on.
So what we have to realize, the moment we water it down and say let's assess what could be acceptable in one state or could be acceptable somewhere else, we may not have any benefits.
What I really want you to consider is that when you talk to countries where they have gone through this painful exercise and have come out and have said there is only one way to go, and this is to create a legal infrastructure for computer signatures to avoid digital and electronic signatures. Countries from Australia to Canada are working on that, because they think it is in the interest of the patient, in the interest of the system.
One should also keep in mind that we need to see, whether a current approach of saying for HIPAA security, that each provider needs to look at their risk, it is not just a tremendous cost to consult and otherwise, where maybe we learn from that and say next time, we don't have the requirement for a provider to go out and establish in a very expensive way what are my risks, where someone is saying, these are your potential risks, and let's have a system which takes care of it.
DR. COHN: I have a question that is along this line. I am really asking for the advice of the panel on this one, because I am hearing those levels of standards and I'm hearing up, down and around, let's have guidelines, let's have whatever.
But as a practicing physician, I worry about having lots of methods of authentication for myself. I could easily imagine some future where there are 30 or 40 different groups that are providing me with PKI, unique identities. I have to remember which one to use when, which doesn't sound to me like a very exciting future. So I tend to -- when I hear words like interoperability which several of you have mentioned at least in passing, I want to ask, how important is interoperability at this point or in the future, is it more of a potential concern rather than a real concern, and if indeed it is, how much guidance do we need to provide to make sure that we don't have this future that I was just portraying to you? Maybe, Jean, you can go first.
MS. NARICISI: We have looked at this area of interoperability, because it is not here yet. What I mean by that is that my digital certificate could maybe not be used for a different application.
But what we have looked at is, we are comparing it to the credit card industry. You might have an American Express card and a VISA card and a library card. You can't use your American Express card at your library. You can use your American Express card at some places, retailers. Maybe you can't use it at every place, but you could use your VISA card at more places.
So in the earlier panel, when they talked about, yes, maybe for authentication, digital certificate, for accessing medical records shouldn't be used at amazon.com. So there are those kinds of things that need to be considered.
So that is how we are looking at it. If there are going to be hundreds of digital certificates that you have to have, authentication services that you have to use, then I think it would be a real problem. But I don't think there will only be one solution, and I don't think industry is evolved enough to be able to say that there should only be a limited number.
DR. COHN: I'll just ask a further question on that. What about if it isn't my library card versus my credit cards, what if it is my insurer wants PKI this way and this other insurer I deal with wants it a whole different way, and this begins to get into 40 or 50 people having different ways out there on these EDI transactions? That is a slightly different situation, isn't it?
MS. NARICISI: It is. It is similar to what we have been dealing with in the past with the transactions and claims. However, it is taking this long for us to get standards out and implemented for these transactions, and in the meantime the technologies are moving along and more and more payors are interested in that content that you have defined, because they can send those kinds of applications over the Internet.
So those are the kinds of things that I think you need to think about. This is not just getting so structured as far as, this is the way it has to be done, because by the time it actually does get implemented, there might be a better way to do it.
MR. WAEGEMAN: Short answer. You might have today two or three different ways you are dealing with, but there are a number of people who are looking at digital certificates in different ways, because we don't need it only for the U.S., we need it internationally. And people are working on that, and it is only a question of time, but what we need in the meantime is the infrastructure for it.
By the time the PKI infrastructure in the U.S. is established, there will be an interoperability, there is no question in my mind. You can ask any expert in that field, and they would probably say the same thing.
MR. WRIGHT: Simon, your problem that you raised of having various ways of dealing with vendors is first, one that is very common to Internet users today. I have some 30 different passwords. Each of the different sites ask me for a password, and I have collected a bunch of these, and it is a lot of trouble to keep up with all of these different passwords and identities I have to keep up with in this site or that site.
It is a problem. I further believe that the assumption that people will be identified by certificates and private keys follows that problem. It says, you are going to be identified by something that you have, that you keep up with. I am not convinced that that is our future. I think it is quite possible we will end up in a different future.
The public key infrastructure classical philosophy has a lot of merit, in that it says there are a lot of challenges and security risks in electronic communication, and those risks can be addressed by using public key algorithms in certain ways.
Part of the classical philosophy with PKI is something I'm not sure I buy into. That is, the only solution is, everybody gets a private key and you walk around with that, or you get a whole bunch of private keys, and you have to keep up with each one of those things, just as we have to keep up with passwords today.
I'm not sure that we are going to like that world, and I'm not sure that society as a whole is going to adopt that. We could find ourselves in a world in a few years where we may need to legally sign a document, where there is a legal requirement. You walk up to a device of some sort and you say, hi, I'm Ben Wright, I'm Dr. Ben Wright, I hereby authorize the transmission of the patient's records, Mrs. John Doe, to wherever and I sign it, bye, that's it. That is your signature; the security is someplace else. The security is public key infrastructure all back here behind the scenes, securing this machine, securing the camera that was capturing my image, securing the voice, identifying the particular time and place when all this took place, creating an audit trail, so it was pretty much known it was Ben Wright who had been at that machine at that particular time and so on. But avoid all of this stuff of requiring me to worry about public key infrastructure and certificate and private keys and multiple keys that different people try to give to me.
I'm not sure. I'm not sure if what I have just suggested to you is the vision of tomorrow. But my point is, there is an awful lot of possible visions here, and I think a lot of people are beginning to rebel against that idea that I have to have a whole bunch of passwords or keys or smart cards that I've got to juggle around and keep up with in order to confirm my identity to some authorities out there.
DR. COHN: Karen, you had a question. You have been very patient.
MS. TRUDEL: I am just seeing a real gap between what I have been hearing this morning, which is very forward thinking, and where a lot of the health profession is today.
We very often when we receive a claim and it comes in in the mail, it may not even have a signature on it. Somebody just says, the signature is in the file. We appear to be getting along well enough with that business case. None of the X12 standards that we have adopted in the first HIPAA transactions even have a requirement for a signature.
So I would be interested in the panel addressing the shorter term aspects of getting from where we are to some level that is maybe not as far along as we have been talking about so far.
MS. NARICISI: But those transactions don't require a signature, but you have to know where they came from. So there has to be some kind of authentication, so you do have authentication. That is when you are sending in a direct line over from my office to whatever clearinghouse I'm going to use to the payor, now things are going to be going over the Internet. We are talking about the online transactions, so that authentication is much more important.
So I think you need to look beyond just that electronic signature, which can be included in a digital certificate and be more like the authentication part of it.
DR. BLAIR: Jean, when you said but we do have authentication, I wasn't clear whether you were saying that the Intel AMA provides authentication, which obviously it does? My first reaction, which is why I was a little confused when you said that was, were you saying that the X12N, financial and administrative transactions in HIPAA, that they have authentication? That is the piece that I am not aware of.
MS. NARICISI: Yes
DR. BLAIR: You're saying they do?
MS. NARICISI: They do, because it comes from doctor so and so, and you have my address, and you have my whatever else you need to pay your claim with. So that is the part of authentication of a claim that you get. It also will say -- in the electronic format it will say where it came from and where it is going to. So that is the form of authentication that there are in the current HIPAA transactions. That is if they are using the X12 standards.
But there will be a lot of HIPAA transactions in the future, and there are some already that aren't going to use those for claims reasons, won't use the X12 transactions. They will be using the content that you defined in those X12 transactions, however.
MR. WAEGEMAN: The transactions are just an intermediate step. The documentation of authentication, the signature, is still in the paper record. If I dispute some transaction, I request of that hospital, of that provider who is giving me the actual documentation, which should show the signature and the information of the individual.
This is very different to the transaction system currently being implemented in France, where they can say, we can save much more by going to a real PKI system.
DR. COHN: Any final comments? We are getting close to lunch.
DR. ZUBELDIA: I am hungry, too. Jean, I cannot disagree with what you said with the external transactions providing authentication. They provide a number authentication, like writing a return address on an envelope when we send a piece of mail. Anybody can write in a return address, and there is nothing illegal against that. The transactions, you say where they came from. They say Dr. Jones whether it is coming from a clearinghouse or it is coming from Dr. Jones or from Dr. Jones' vendor, it still is Dr. Jones.
I think that the security NPRM requires a level of strong authentication. That is independent of signatures. Strong authentication is very important, it is essential in health care for the medical record and for other transactions. But that has nothing to do with the signatures. The case for the signature is different. The case for the signature is to prove that Dr. Jones actually signed this prescription, or Dr. Jones actually signed this medical record.
I think we need to keep that in mind, that those are two different things, even though the technology used for both, as in the case for PKI, may be exactly the same. But it is two different business purposes.
MS. NARICISI: Authentication as in the X12 standards won't fall under the same definition as we know authentication, to define something in a digital certificate. It is not the same authentication, but it does tell you who the claim comes from, and for the payment to go somewhere. So that is a limited use, but that is the whole thing. None of the HIPAA transactions currently require a signature, even if it is on paper. It can say signature on file.
We are talking more for the future with the medical records, and those will need to have authentication and signatures.
DR. COHN: I think I want to thank the panel. I think everybody has asked all their questions. I want to thank the panel for a wonderful discussion. Thank you all very much.
We will adjourn now for about 45 minutes. We will reconvene at 1:50, and thank you all.
(The meeting recessed for lunch at 1:05 p.m., to reconvene at 1:50 p.m.)
DR. COHN: Good afternoon. This is the afternoon session for the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics. This is Panel 3, which is focused on government activities and electronic signatures.
Our first testifier is Steve Bruck, who I believe is going to be doing this with Patricia Good. Is that --
MS. GOOD: Reverse the order probably.
DR. COHN: Reverse the order. Okay. Patricia, you want to go first then.
Agenda Item: Government and Electronic Signatures
MS. GOOD: I am from the Drug Enforcement Administration. Our interest in this area revolves around controlled substances. The federal law requires that parties who issue orders for controlled substances and those who fill them are registered with DEA and the transactions in our case are between these two professional parties, not between a registered party and DEA. So, we are not in the project you will see -- in the handout we provided, we are not discussing records or reports provided to DEA, but rather transactions between in this case a physician writing a prescription and a pharmacy filling it.
Under the current law and regulations, Schedule 2, the most highly controlled prescriptions must be on a written document at the moment with a manual signature. So, a pharmacy cannot fill such a prescription until they have that document in hand signed by the physician.
For years, the pharmacy industry has asked us to move into the realm of electronic prescription and some of the considerations that we have to look at as we are moving in that direction are what are the requirements until our law to maintain controls against diversion of the controlled substances, as well as the business reasons to move in this direction and the balance between government control and the business practices.
We began looking at this at the request of the pharmacy industry primarily for one very valid reason. The pharmacist who fills a prescription bears reliability for verifying that the writer of it is authorized to write that prescription under the Controlled Substances Act.
When PKI technology became more widely discussed, we saw under the applications and services it offered, a way to address our concerns about authentication of the parties sending the message, which would be the prescriber, building into the security services their authenticity as a physician, as a registrant with DEA. We saw as a way to assure the pharmacist that that prescription would be coming from no one other than that particular licensed and registered physician.
We also saw it as a way to guarantee message integrity, to prevent forgeries and alterations of prescriptions in transit and as a way for the pharmacist's liability in verifying the registration status of the prescriber to be sort of taken off the hook somewhat.
So, with that in mind we have contracted with PEC Solutions, which is what Steve Bruck represents, to design a concept of operations for us. That is the stage we are in at the moment. The paper that you have been provided is a concept document as to where we are headed with the regulations used that we expect to make early in this year.
The scenario that we envision is to have certification authorities, issue digital certifications to the physicians who wished to participate in this. Obviously, it is a voluntary program. There is no mandate that prescriptions must be transmitted electronically. They can still be transmitted on paper and for the Schedule 3, 4 and 5, they can still be transmitted via telephone or fax.
What the allowance and the standards to these are to enable the transmission by electronic means. Our goal is to set minimum standards that can be met regardless of the type of technology to be used, to place those standards in our regulations and allow for forces within the industry to more or less meet those standards and begin this type of operation.
In order to -- down to interoperability and put some control around the framework, we envision DEA operating a route certification authority under which anyone who wanted to become a certification authority would operate to issue the digital certificates to the almost 1 million practitioners that exist today.
We see that as the way of guaranteeing that the practitioner or the pharmacy who wants to verify a cert(?) from a prescription could do that regardless of what CA it was issued by because they would always pass through the DEA for verification lists and other issues that would not necessarily cross relate if they were all issued by independent CAs.
We are, as I said, still in the concept stages. We have not proposed any regulations yet. What we have done is a complete review of the current industry status. PEC, and Steve can address this a little more, has interviewed entities from all different areas that would be affected by this, like medical practitioners, pharmacy practitioners and health and regulatory enforcement agencies and, of course, DEA.
We are looking at this from the standpoint of balancing the business practice and also granting the assurance and security that the issue of forgery and certification of the sending party and their credentialing can be certified. Right now, as I said, that requirement is placed squarely in the lap of the pharmacists.
In a nutshell, that is the framework that we are trying to work under. The technical aspects of it and the timetable are still all up for debate in the Federal Register, but after all of our industry's views, we are leading towards using digital signatures as opposed to electronic in these areas where the issue is certifying that the two parties are who they say they are.
There are other applications here. For example, once the pharmacy receives the prescription where there is no longer a need to authenticate anything to a third party, where the electronic signature for recordkeeping purposes is sufficient. For example, the pharmacist who is filling a prescription has no need to validate his identity to any third party so that record will simply bear an electronic signature of the pharmacist who filled it.
Likewise, any other recordkeeping or reporting on the meds that come into DEA from the drug industry, those will be -- primarily electronic signature will be acceptable. There is one other application that we are looking at digital signature and that is for the ordering process of drugs between wholesaler and pharmacy, which is a slightly different issue and is not exactly a health record. So, I won't get into the detail here. But it is moving on a parallel path.
I would like Steve a little bit to maybe fill in some of the technical blanks that I have left since I am not the technical person. I am the policy person. I think that probably gives you the framework that will maybe -- maybe to ask us some questions.
Steve.
MR. BRUCK: Hi. I can elaborate on the architecture that we are contemplating for this PKI.
My name is Steve Bruck. I am with PEC Solutions. With regard to that framework, the high level concept behind that is this idea of a DEA route certification authority. That framework was really proposed in order to satisfy three key requirements.
The first requirements is trust in their operability. As Pat mentioned, what we would like to do here is provide a mechanism for industry certification authorities, those certification authorities that see this as a niche that they would like to pursue to give these organizations the opportunity to go ahead and do that.
But if you understand PKI, you must know that there are trust interoperability issues with respect to PKI; namely, the idea of cross certification between these PKIs. The key issue that we want to try and avoid and resolve through this design would be to try to ensure that when a pharmacy receives a prescription, there isn't an issue as to whether or not that pharmacy happens to trust the CA that issued that certification to the particular practitioner.
So, if we want to give the marketplace enough flexibility to have as many certification authorities as might be commercially viable. We also want to put in place a framework that facilitates this trust in our operability so we don't get into situations where prescriptions cannot be filled because a particular pharmacy doesn't trust a particular CA that happened to issue a certificate to some doctor.
So, trust in our operability was one key consideration. The second key consideration had to do with performance, had to do with availability, just understanding the sheer volume of prescriptions in the United States rated at 3 billion per year and if you look at what the ratio of controlled substance prescriptions are within that world, you have approximately 15 percent. You are looking at hundreds of millions of prescriptions every year that would need to be validated by a pharmacy.
So, what we are trying to do here is insulate DEA from that incredible work load and give that to the organizations that are out there that are best suited to perform that duty; namely, industry and commercial certification authorities. So, looking at our design for this framework, the DEA acts as a facilitator for trust between these certification authorities and the certification authorities, those are the entities that are responsible for issuing certificates, enrolling doctors and publishing CRL information.
So, what we are trying to build here really is a pyramid, which distributes responsibility for system availability with a primary responsibility at these subordinate certification authorities. DEA would operate a route. It would give certificate status information regarding these subordinate CAs, which, by the way, would have to be approved by the DEA. But I think through the intelligent use of CRL lifetimes, what we are going to do here is insulate the whole prescription world from government impact to the success or failure of that prescription.
Implicit in this framework is a DEA certificate policy. So, what we are really talking about here is a level of assurance that needs to be implemented for a specific application; namely electronic prescriptions for controlled substances. As Pat alluded to, we did a significant amount of research and held numerous meetings with health care community of interest to try and discover what the key hot buttons of these different organizations were.
One of the key drivers that we identified had to do with knowing whether or not a practitioner is, in fact, a DEA registrant, knowing whether the practitioner, person issuing the prescription does, in fact, have the credentials to prescribe, for instance, a Schedule 2, a Schedule 3 drug. So, you have a situation where the pharmacy needs to have some guarantee as to what is going on with this digital certificate.
So, this certificate policy that we are in the process of developing will identify the set of provisions that address enrollment, the set of provisions that address private key safeguarding, all of the policy issues that come together that turn this electronic certificate into a real valid credential that a pharmacy can really trust because there is a sound foundation behind the way it is delivered, the way it is safeguarded by the practitioner.
So, this certificate policy now in the document that you have, we address the different obligations that we anticipate applying participating practitioners, participating pharmacies and these industry certification authorities.
So, so far we have mentioned two key factors that influence the approach; namely, trust in our operability, ensuring performance and availability. The third factor has to do with the regulatory aspect.
The issue that we struggled with there was really in a nutshell, DEA registers doctors, DEA registers pharmacies. These people have DEA numbers and, therefore, they have accepted a responsibility to operate in a certain manner. There is really no relationship to date between DEA and with commercial certification authorities.
What action would DEA be able to take if a situation arose based on DEA policy, DEA has specified a certain set of provisions that need to be followed. What happens when a certification authority doesn't follow these provisions? Ultimately, we would like to have some form of some mechanism where DEA can enforce this policy. So, the idea of a route certification authority lends itself to that.
I guess that is the general overview of how we came to that particular architecture.
DR. COHN: Anymore comments from either of you? Okay. We will handle questions after we have done all the panelists.
Stewart Crumpler, please.
MR. CRUMPLER: I am Stewart Crumpler. I am with the Food and Drug Administration.
I would like to talk to you about 21 CFR Part 11. It is our regulation regarding electronic records and electronic signatures. It is a rule that is already in place. It has been in place for about three years. Like the experience with DEA, we were approached about 1990 by the pharmaceutical industry. They asked what it would take for FDA to accept electronic records in lieu of hard copy records and electronic signatures in lieu of handwritten signatures. And we set about trying to examine that and spent quite a long time in trying to develop a regulation probably prior to or at about the same time that the standards you are talking about today were under development.
So, our regulation is a lot more general than some of the things that you have heard. It lays out the framework. There are lots of ways to comply with the regulation and it is intended to do the minimal standards under which we would accept electronic signatures in this case as legally binding.
We are looking for trustworthiness, reliability and we need to have systems that are compatible with our public health mission. You have a copy of both the Federal Register notice with the final rule and some slides from which I am speaking. You will notice in the Federal Register notice that we have administrative, procedural and technological requirements. We believe those are necessary. As you have heard this morning, there is more to this than just the technological solution. There are some administrative and procedural things that need to be in place as well in terms of making sure that the party that is identified is, in fact, the right person.
In terms of implementation, this regulation went into effect August 20th, 1997. We are enforcing the regulation now. We are doing that rather flexibly because the industry -- I guess if there is one thing that I can tell you in terms of our experience, you can expect that the parties that are impacted about what you are doing are probably not going to move until you actually have something in place.
It doesn't matter too much how much you tell them that it is coming, forecast it or whatever until it is actually in place. They don't begin to move. This is something that has a fairly long lead time in terms of implementation.
Our implementation applies not only to systems in the future. It applies to systems already in place. So, we have a built-in legacy problem in that the legacy systems have difficulty in complying with several of our provisions, the most important of those are the requirement for a secure computer-generated auto trail of all transactions, creation, deletion, modification of records and the requirement for archiving of information.
The archiving situation is one where we believe that systems can be migrated from one platform to another in a validated way, but that is something that the industry is really struggling with.
I mentioned at lunch to Simon that this is a very expansive rule. It covers all FDA regulated industries. Those industries account for about 25 cents out of every dollar spent in the United States, about 25 of the gross national product. So, the records and signatures that those industries decide to use and decide to take on electronically are ones that are very important. Pharmaceuticals, foods, medical devices, consumer electronics, all those are impacted if they choose to keep their records electronically or use electronic signatures.
We have divided our requirements based on closed systems and open systems. I think the kind of systems that you are talking about are probably open systems. That is why you are talking about digital signatures. We also have closed systems where the manufacturer is completely in control of the content of their information.
In that kind of a situation, we are looking at validation and audit trails and record retention issues, as well as various kinds of checks; system checks, device checks, authority checks to make sure that the transactions are appropriate.
Our electronic signature requirements still recognize both biometrics and non-biometric approaches. You have heard a lot about biometric approaches, which uses a non-biometric signature. They have -- well, actually, whenever they use either biometric or non-biometric signature capabilities, they have to use one of -- at least one of the features, security features for that signature system -- I am sorry, at least two.
If there is a non-biometric system and they have, let's say a password and a user ID, they would have to enter both of those to start a series of signings, but they could continue to sign a series of documents and use only one of those features for the subsequent signings in any one period of time, any one period of continuous access.
We have requirements that -- and these are procedural and administrative requirements that require that the electronic signature mechanism has to be unique to the individual signer, not reusable or reassignable and has to be linked to the records so they cannot be excised, copied or transferred so as to falsify the record by ordinary means.
What that typically means is that it takes at least two people in order to falsify the record. That is important for us because two people constitute a conspiracy and we are then into criminal follow-up instead of civil.
We have specific requirements in terms of what electronic records have to contain. In terms of the signature, the current name of the signer, the date and time of the signature and the meaning of the signature are all requirements. That information has to be readable both in the electronic display and any printout.
If that manufacturer decides that they want to use electronic signatures, they have to certify to the FDA their intent to do so; that is, in the form of a letter with a handwritten signature. They can make a one-time certification that covers multiple facilities and all employees for all times if they want to or they can individually certify individual facilities. But they do have to provide a certification to us that they intend to us e electronic signatures and that those are going to be illegal equivalent of a handwritten signature.
I am not going to go into a whole lot more about the details here. I know your time is limited. The information regarding 21 CFR Part 11 is available on our web site and you have the web site address there.
We are currently in the process of developing further guidance on its implementation.
Thank you very much for the opportunity to testify.
DR. COHN: Thank you very much.
Jan Lovorn.
MS. LOVORN: Please bear with me. I have been very sick and I am hoping I am keep my voice long enough for this.
First of all, let me give you a little bit of my background. My name is Jan Lovorn. I just recently started as the chief privacy officer for a company called Protegrity that is using these standards that have been developed in these regulations to work in the health care arena, as well as some areas.
I am former chair of ASTM E3120 and was involved in writing a lot of the standards to meet the regulations. I actually worked with HCFA and provided input into information for the regulations. The use of digital signatures is something that is a very big passion with me and I hope that comes across.
I have been in security about 15 years. I was really introduced to the PKI type concept about seven or eight years ago and I immediately saw its applicability to health care. There are lots of things going on in health care that need the kind of attributes or the features that digital signatures and a PKI provide.
What I am going to do is kind of step through a thought process that happened. I started working in the ASTM standards arena when Peter Waegeman was still chair of ASTM E3120 on data and system security for health information. We came up with a standard called the Standard Guide for Electronic Authentication of Health Care Information. The reason I want to bring that one up specifically is that in that standard we looked at business requirements not regulatory requirements for trying to deal with electronic information.
I want to read you a very short list of those attributes that we thought were really necessary for doing any kind of electronic process of health care information and if you were going to put any kind of signature on it. The first thing that we identified was non-repudiation. The second was integrity of the information. The third was the secure user authentication, the ability to do multiple signatures across a document or piece of information, being able to have signature attributes, such as a date/time stamp or a location that would be involved. You also need to do counter signatures across documents. Here are a couple that are really important.
One is that signatures could be transported across organizations. As we talk about more and more having open systems in the exchange of information, it is very important that whatever kind of authentication and non-repudiation that you have in one organization can be verified in another organization. Please keep that in mind.
The fact that it is interoperable, that I don't have to funny, funky things to integrate this across many systems for example, for example, a hospital in La Jolla, California, for example, if someone is very ill on the East Coast, say at Johns Hopkins can be able to send electronically the information and they can verify that it got there and nothing was changed and that who sent it was a legitimate person from the organization.
Another thing that was very important was independent verifiability. Some third party could also verify that this stuff was what it was. The integrity was there and that the authentication was there and also the continuity of signature capability. As we all know, medical records are not something that is here one day and gone the next, like other industries, for example, in financial, where you have one transaction and you might want to be able to keep it from one to five years.
The State of Minnesota requires medical records to be maintained for a minimum of 80 years and nearly all states require pediatric records to be maintained and verifiable for 21 years. So, these are the requirements that we originally set down in ASTM as business requirements, not necessarily regulatory, though they ended up being in some of the regulations.
Kathleen Frawley was involved in that. Peter Waegeman was involved in that and several people from the health care places, nurses, doctors, medical records people, vendors sat down at a table and debated this for about two years. These are the requirements that we identified were necessary to do the exchange of electronic information in the health care industry.
Based on that, I would like to move forward and do a little more talking. I personally have identified over 200 kinds of players in the health care market that will be touching patient identifiable information, who will be exchanging information. You know, it is really important that when we do this that we be able to keep the information private and that we be able to maintain the information for its integrity.
As an individual, I have been looking at E-SIGN. I have been looking at other things for the company that I work for to make sure this works. While I was also chair of ASTM, I was involved in ANSI committees and if you will go
-- I have an old version of it but you can go on ASTM's web site and we have a document out. It is called Status For Security and Electronic Signatures in Health Care. It is an integral document. I don't know remember how much it costs.
You can have them mail a copy to you or you can get it electronically and its relatively inexpensive. It is only like 50 bucks. Or if you join ASTM, which is really nice. It is 65 bucks. And you get a copy of this every year with all the updated standards. That is my pitch for them.
What I would like to go on about digital signatures is is I really feel in my work -- I have worked in the IRS and done this and I have worked in this in some health care organizations doing this or providing input to them. It is really important to look at what the requirements are and what the business requirements are and to look at the interoperability. I think it is very important for this that we have a standards base saying that we may not mandate that everybody has to use digital signatures, but we definitely say if you use them, this is how you need to do them.
Electronics signatures, I mean, the digitized stuff, while it is very, very good, if there is not some way to bind an individual back to what the action was or to the document, then you have lost your non-repudiation capability. This is very, very important.
A few years ago there was a survey done that 37 percent of all malpractice claims had to be settled out of court because there was not enough information to prove or disprove what people had done. As we know, this is a large part of the medical industry right now is this malpractice and protecting everybody's interest in the way things are done.
The more and more that we do in the electronic exchange of information the easier it is for some of the stuff to get documented and you are able to prove with digital signatures whether someone did do something or whether somebody did not do something. It goes back and you can relate it to an individual.
I can say Surgeon A in the operating room did these actions and the surgeon that was assisting him did these kinds of actions because they will have signed off on it and you can prove that they are who they are and they are the one that did it.
I guess what I would like to finish up with is I have had a lot of experience in installing this in different systems. I am a systems engineer with a math background. I know that technically this system will work and if you sit down and look at it what it can save you in labor costs for implementing some of the other solutions.
I think you will find over the long haul that this is cheaper and it definitely provides lots of benefits in the malpractice area, as the gentleman over here was talking about, for prescriptions, for drug trial information, everywhere this information has to have integrity.
Another thing that you might want to remember is that companies like SmithKline Beecham send back a million test results every night via telephone lines and there are no checks on these to see if they have integrity. Digital signatures is a way that would do this. Electronic signatures would not.
So, I think you need to consider that all in the context.
What I would like to say on the ending of my talk is the fact that I recommend that digital signatures be selected for implementation under HIPAA. At the very least, it is an option. Do not take it out of this because it is really important and there are industries that are starting to use this for business reasons and they need to have a way of how to implement it and make it interoperable.
Thank you.
DR. COHN: Okay, Jan. Thank you very much. And your voice did very well.
MS. LOVORN: Thank you.
DR. COHN: Benjamin Wright.
MR. WRIGHT: I introduced myself in the previous panel.
I wish here to give a brief overview of some of the uses of electronic signatures and digital signatures for legal government transactions and hope to introduce you to the breadth of approaches that people are trying around the world. One example of an electronic signature in the court system is in Guinnette(?) County, Georgia, which is a suburban county of Atlanta.
Police officers and judges interact with each other through a video conference system using their computers and the judges and police officers are required by law to sign documents where you truly have a legal requirement that says thou shalt sign the court order. The way that the judge and the police officers sign the documents is through a handwritten autograph captured on a tablet where a biometric measurement of the handwritten autograph is captured and then bound to the document that is required to be signed.
A completely different kind of approach is what the Internal Revenue Service has been doing for the past two years. How many of you have received in the past two years a postcard from the Internal Revenue Service saying here is a PIN number for signing your electronic tax return. There are some 800,000 Americans who have been eligible to participate in this pilot project. What has occurred at my household is that my wife and I have received a single postcard in the past two years from the Internal Revenue Service.
You open up the card and it says that Benjamin's PIN number is this number and Rebecca's PIN number is this other PIN number. And the Internal Revenue Service has asked people to sign their tax returns purely electronically through their computer just by typing in the PIN number.
An interesting commentary on that is that historically in my household I have always been the one who gets the honorable duty of preparing the tax return. So, historically, I filled it out on paper and I have never -- it has never even occurred to me that I would ever write my wife's signature on that tax return. There is a lot of stigma associated with the idea that I would write my wife's signature. So, I always take it to her and I ask her to sign it and she always says, well, I want my lawyer to read this before I sign it. We go through that little routine and then she signs it and we go on.
Now, think about the mechanics and think about the psychology of a PIN number coming from the Internal Revenue Service. When my wife -- if my wife ever receives a piece of paper addressed to her that says that it is from the IRS, as far as she is concerned, it is addressed to B-e-n, to me. It is not addressed to her because as far as she is concerned, I am the only one who deals with taxes and she pays no attention to it whatsoever.
So, imagine here I am working on my computer. It is April 15th. It is time to now file the tax return and it says I have got to sign and my wife has to sign as well. How do you think she is going to react if I say, well, I have to get up out of my desk and I have to go find her someplace and then ask her to sit down before the computer and type in her PIN number. She is going to say "What?" Why do I have to type in the PIN number? You have got it right there. In fact, the typical American is going to say there is no stigma associated with me typing my wife's PIN number. The Internal Revenue Service has not educated me to believe that my wife's PIN number is hers and only hers and that it constitutes criminal forgery for me to type her PIN number in.
IRS has talked this one through. They have thought it through and they decided for their very unique specific purposes, they don't care. At the end of the day, they feel like the biggest problem there is between me and my wife. It is not between us and IRS. My wife and I can sort that one out if we get divorced and she claims that I forged her signature. That is my problem. IRS doesn't care about it.
It is an interesting commentary on the use of what I call the transferable signature. Transferable signature means a PIN, a card, a key or something that you can transfer and you run the risk that people get confused or you get even conflicts between, you know, one spouse and another as to whose PIN number that actually belongs to and who should use it.
It is a completely different type of system. I don't have direct experience with this, but I have heard about it from a couple of different sources. The country of Spain, Italy and Ireland each have aggressive systems for using public key digital signatures with taxpayers who are filing documents through the worldwide web so that the taxpayer obtains the certificate and the private key and downloads it onto his or her browser and then uses that signing capability within the browser to sign the documents electronically.
I do not know whether those countries have an issue as to the difference between a wife and a husband and whether there would be a problem. In my household, my guess is that if the IRS required us and asked us to download two certificates, it would only be one person who really does download the certificates. I would download one for myself. I would download another one for my wife.
My wife would pay no attention to it whatsoever and if I asked her to pay attention to it, she would protest and say, look, that is your responsibility. I do other things in the household.
In any event, that is, so I am told, an example of a public key infrastructure to the mass market that people are trying with some zeal. A completely different type of system involving government signatures is what is happening in the mortgage industry. There are several different companies who are vigorously going after the mortgage industry, where people buy houses and sign documents to say I buy this property or I sell this property and I take a mortgage on my house.
For those of you who have bought houses, you know it is a very paper intensive process, lots of signatures on lots and lots of documents, companies like ClosingGuard.Com are endeavoring to streamline that process with electronic methods. ClosingGuard has discovered there are some things you can do electronically and there are a few things that today, given the state of government, you simply can't do them electronically.
So, what ClosingGuard does is they say the home buyer should go show up at the real estate office. A home buyer cannot do this from home, cannot today buy that land and sign the mortgage from home or from his apartment or wherever he is, but he should go to the real estate agent's office, the settlement agent's office and there is a physical process that occurs.
The home buyer doesn't have a private key and a certificate because that is a lot of trouble to try to give them a certificate just for this one transaction. The home buyer writes his name on a digital tablet, which is securely bound to the documents themselves. It is notarized by a notary, who signs her name, using that digital tablet, capturing the biometric measurements of the signature and, finally, the agent who is sponsoring this, wraps the whole thing with a private key using public key infrastructure.
Of course that agent is a particular person who has been specially trained, has the special equipment and resources to keep up with the private key, understand what is going on and so on.
In that process, most of the documentation ends up to be electronic. However, the county court clerk, who received mortgages and deeds for final filing in most cases are not able to deal with the electronic document and, therefore, the final mortgage and the final deed are printed out and actually delivered on paper to the county recorder in most cases.
A final example of a government agency that was struggling with how to deal with electronic filings and electronic signatures was the Securities and Exchange Commission, which has been receiving electronic filings from corporations for 15 years or -- actually, it is almost 20 years, through the EDGAR(?) Program. The securities laws say that annual reports and quarterly reports from corporations are supposed to be signed. There is a legal requirement that the documents be signed.
However, the Securities and Exchange Commission wanted to receive the information electronically. How do we get the documents signed, especially when the requirement requires, say, that all of the members of the board of directors of the corporation sign the document that is submitted.
The solution was that the corporation, which is a highly regulated organization -- it is very well known -- it is a publicly-held company -- their corporation gets a password. The corporation uses a password to submit the filings. The corporation types into the words of the filing signed by CEO, signed by Director John Doe, et cetera, and what the SEC gets is just an electronic filing that was just authenticated with the password and the fact that it is a relatively closed type of system.
But the actual legal signatures from the board of directors and from the officers comes from the corporation having a duty to go get paper documents signed by each one of those people and they keep the paper document on file. The SEC doesn't need that paper and doesn't get it, but there is a legal -- there is a formal paper signature captured for each one of those people.
The reason I go through this laundry list of these various kinds of approaches to electronic signatures is to give you just a taste of the diversity of approaches that the government has come up with. I anticipate more diversity.
Thank you.
DR. COHN: Thank you, Benjamin.
Is Dr. Gunther Schadow in the audience? No. Okay.
Why don't we go to questions?
Kathleen, do you have something?
MS. FRAWLEY: This question is directed to Patricia and Steve.
In your concept paper that you provided, you indicated you are planning on registering over 800,000 DEA registered practitioners, which I would suspect is the major percentage of the practicing physicians in this country and over 50,000 pharmacists.
I am curious, have you given any thought as to whether your models could be used for other health care practitioners? We are struggling right now with this whole concept of whether your route CA could be used for registering, you know, nurses, you know, lab technicians, you know, allied health professionals, other providers.
MS. GOOD: The route that we intend to set up will have to meet the standards that dictate who can be in your game to write controlled substance prescriptions. The only people that can be in there are DEA registrants. That includes practitioners like physicians, dentists, veterinarians, who have state authority to write prescriptions for controlled substances. We need mid level practitioners with that same authority.
If they are not a controlled substance authorized medical person, then they would not meet the criteria for inclusion in our certificate under our route. That is not to say that someone else, a CA operating under our route couldn't as a sub-business also certify other people for other purposes.
So, I guess the answer is sort of "yes" and "no." Under our route particularly, no, because the certificate policies would require that the main criteria would be that the person have a DEA registration.
MS. FRAWLEY: Thank you.
DR. COHN: Actually, I have a follow-on question about that because as I was listening to what you were planning with all this, I was sort of reflecting on the fact that there is actually a final rule at some point coming out, related to providers. There is a provider ID, plus a provider system.
Now, obviously, those providers are way beyond what you are talking about. There are physicians and there are practitioners and all sorts of varieties of non-physicians, but it seems like there ought to be some -- I may not be smart enough to figure out what the relationship is, but it seems like there are independent efforts that may be should be a little closer together.
MS. GOOD: Our philosophy from the beginning has been that our universe captures pretty much everyone that the health care universe captures, but our universe is much smaller.
So, if someone wants -- some commercial entity goes beyond what we require and captures everyone, we can certainly certify that entity, do more than what we ask, but we can't take on the role of becoming certifier. We don't have the room with DEA. Does that make sense?
I mean, we as DEA are not going to set up an operating entity that goes beyond the authorities of what DEA can do. In other words, we are not going to start certifying physical therapists under our group because we have no venue there. But it could work the other way around, where HCFA entities certified both DEA players and the rest of the world.
MR. BRUCK: You know, the certificate policy that DEA will publish will identify the strict sets of provisions that impact credentialing these unique individuals that have this unique credential; namely, this ability to prescribe this class of substance. So, that is a fairly large hurdle for somebody to get over. It is not meant that everybody would have that ability.
MS. LOVORN: That is one of the neat things about using the public key infrastructure and using digital signatures is that you can have multiple layers of credentialing your multiple entities with one issuing of the identity certificate. For example, in our particular area, Washington, D.C., doctors and nurses can practice in one, two or three of the jurisdictions and then in credentialing across the three and the public key infrastructure will allow you to maintain that credentialing, based on the area that they are in and it doesn't matter where the route CA is. You can have subordinate CA's or subordinate certificates or what -- and there is a new concept coming out called attribute certificates, but I won't go into that here -- that allows you to do those kinds of things, to have somebody have credentialing in a couple of different areas and then be able to match them up to allow people to do things or to record what they did.
DR. COHN: Kepa.
DR. ZUBELDIA: I have question here.
This morning we heard about how important it is to be technology unspecific so we don't paint ourselves into a corner. The DEA is doing something that it very technology specific. In fact, it looks like it is very well-defined technology for prescriptions. I would like to hear from the DEA and from the FDA why those two approaches -- why very specific technology dependent rules apply to the DEA and why the FDA is setting generic rules and which one do you think would work best as you have two different experiences. Which one do you think would work best for all of health care?
MS. GOOD: I will speak for DEA. We are setting standards for the qualifications that a system must have and, therefore, to meet our standards, we are not going to define the PKIs. Right now, PKI is the only thing that rises to that level. What we are going to set forth are the things that the system must do, the things that the verification process must ensure. As things develop in the technology world and other things rise to meet that level, then they, too, will be included.
But at the moment, we are using them interchangeably because PKI is the only thing that now does all of those things. Since we are looking at not simply the same areas of maintenance of health care workers within some institutions, we are looking at the aspect of fraudulent prescriptions and drug diversion from outside entities that could be so prolific using electronic means. We are looking at the best ways to certify to a pharmacist that the validity of a prescription and a prescriber can be met.
To say that it is PKI now is simply because that is the only thing that guarantees those attributes. That could change.
MR. CRUMPLER: In terms of FDA, I think that the scope of what we are dealing with is far broader than what DEA is talking about. They have a very prescribed application and they may be able to accommodate that through PKI or through their own digital certification program. We have specifically avoided that and that is discussed in the preamble of our regulation.
We are not in the business of developing standards and we are not in the business of certifying a body. We left it to the industry to come up with their own solution. Our only requirement is that what they come up with has to work. So, they are on the hook for what they choose to be the intent of the regulations, as specified in the regulations.
I might point out that for open systems -- I mentioned closed systems, but for open systems we also specify that our manufacturers use encryption and digital signature standards as appropriate. So, we have the same kind of concerns for open systems where the manufacturer is not in total control of the content of the transmission.
DR. COHN: Mel, did you have a --
DR. GREBERMAN: I am also from the FDA. So, I would like to expand a few of the points my colleague made. Basically, many of the issues are related to many other issues besides electronic signatures, of interest to us. For example, the availability of drugs and prescribing them, both electronically and availability over the Internet is of treat interest to us, as I am sure you know, and clearly the issue of medical mistakes, reducing medical mistakes is of great interest.
I just wonder whether you have had some contact with the FDA on these issues? If not, I will be glad to link you up with the right people.
MS. GOOD: Not directly, no, we have spoken to a few people here and there. We are looking at the Institute of Medicine's report. So, we are very aware of the medical mistakes issue and that is obviously a big plus for what we are looking at in helping to fix that.
We also have committee working on the Internet prescribing issues, not separate and apart from this, but, yes, we are very much involved in that.
DR. GREBERMAN: Then maybe the other group in terms of the medical mistake issue is the Quality Interagency Coordination Task Force, which is not just HHS, but all federal agencies that are concerned with this issue and I wondered whether you might --
MS. GOOD: Well, we are indirectly concerned in that we see this as a way to help fix it, but in terms of it being one of our issues, it really isn't.
DR. GREBERMAN: They might like to know about it.
MS. GOOD: Yes, yes.
DR. GREBERMAN: We can talk later.
DR. COHN: Mike.
DR. FITZMAURICE: I guess my question was I look around the country and I see AMA and Intel linking up together to identify doctors. California is starting the same kind of process. Are these procedures self contained within DEA and within FDA or does it admit to linking up and partnering with private sector entities that are doing somewhat the same thing, if you can develop the degree of trust that you need.
MS. GOOD: Are you speaking about the system of getting people involved with the state system's work? Is that what you mean?
DR. FITZMAURICE: And making the system work, yes.
MS. GOOD: Yes. Our intention is that when you talk about establishing a route and allowing subordinate CAs to work under route to meet the policy standards that we set out, we envision that groups like this feeding the CAs under our route. In fact, that is what we hope will happen. It could be entities like the AMA. It could be entities they work through. It could be state medical boards, state pharmacy boards. There are many different appearances they could take.
MR. CRUMPLER: In our case, we are not a CA and we don't have that aspect of the program within our purview. We have taken it upon ourselves to try to link up our regulated manufacturers with vendors, who have success stories to tell. We had a conference in Philadelphia that was attended by 900 people in June to have the vendors and regulated industry come together and share both the difficulties they have had in complying with Part 11 and also some of the successes that they have had.
What we have found from that conference is that a lot of the industry, the regulated industry, is looking for turnkey solutions and there are no turnkey solutions. Everything has to be customized to fit the situation and there is some significant degree of effort and cost associated with a particular solution for a particular manufacturer.
MS. GOOD: I would like to say as a follow-up to that, DEA has a number of records required to be kept, much like FDA does in terms of what manufacturers, distributors and pharmacies must retain in their own records. For those, we are not discussing this PKI technology. We are doing much like what FDA is suggesting.
In fact, the manufacturers have simply asked us is the -- if our system is approved by FDA, does that meet your requirements. Our regulations there simply state you must keep records of A, B and C. In those cases, we will not be going to digital signature.
The digital signature elements only come into play when there is a legal mandate that the transfer of something be between two registered parties and we are using that as a certifying mechanism. So, it is a little different.
MR. CRUMPLER: If I could follow up on just that comment, just one item that I failed to site clearly earlier, we started out in 1992 trying to develop an electronic signature regulation. Over the period of about six years, we discovered that we really needed to have an electronic records and electronic signatures regulation.
It was very difficult to decouple the two. That is the reason why our regulation is written the way it is. So, you might want to think about some of the issues associated; for instance, electronic auto trails is a big, big issue in our industries. It is one of the areas that is most difficult for them to comply with.
But it is absolutely essential in terms of establishing audit ability and integrity of the overall system.
DR. COHN: Melvyn, do you have a comment?
DR. GREBERMAN: Yes, just one small comment.
Basically, I think, clearly there is some overlap of interest and I think the issue of the consistency in terms of the approaches is useful because, clearly, the same providers who will prescribe will also have to submit adverse event reports to us and send us information electronically increasingly more in the future, too. You know, the ability to be able to use systems that are somewhat coordinated could be helpful, I think, in that regard.
MS. GOOD: We are not doing anything about systems. We are just --
DR. GREBERMAN: I am using the term "system" in a broad sense.
MS. GOOD: Because I am not sure there is that much of an overlap with that.
DR. COHN: Jeff, did you have a question?
MR. BLAIR: Thank you.
In the testimony that we have received so far, Kepa observed that especially our early panels were encouraging us to avoid looking at standards that would be technology dependent. If we step back from that, it wasn't entirely clear from the -- it wasn't entirely clear to me, Jan, from your testimony the degree to which ASTM guidelines for electronic signatures were technology independent. It seemed to me as if they pretty much described the -- from what you were telling us -- by the way, it has been three and a half or four years since I have looked at, you know, those standards. So, I don't know what they look like now.
It seemed as if they were setting forth -- you correct me if I am wrong -- the requirements for authentication, for data integrity, for non-repudiation and doing it in some detail in terms of some level of specificity in terms of those requirements, it did seem to drive towards PKI and here is the gist of my question.
Some of the folks that were testifying today were suggesting that there were technologies, such as voice recognition or biometrics, which might be useful for authentication. Does the ASTM standard allow for somebody to use, for example, a combination of technologies like PKI that meets most of those requirements, but that they could also fold in other technologies, such as voice recognition or biometrics or other things?
MS. LOVORN: Yes, it does. I only mentioned that one standard because I want to look at the requirements that the business -- that were developed for business reasons. We actually have five different standards. I am going to read you the titles of them because it may address some of what you are talking about.
As a result of the development of E1762, which is the one I talked about on electronic authentication, we have developed data on user authentication and authorization that goes then and talks about as part of authentication. You can use a choice of these things. We have identified within there that you can use this one or you should use a combination of these two or three to do that.
We also have a standard specifically on digital signatures, on how they should be done with minimum key links identified and implementation that way. If you want to use them separate and apart from the PKI infrastructure
-- we also have a technical security framework for health care information and they have one on the Internet Intranet, the use of that, and doing authentication at that level. Actually, HCFA took a large part of the provisional standard for Internet Intranet and put it in their Internet use policy.
Those are just the technical specifications. We also have some other standards written at the policy level for a standard guide for confidentiality, privacy, access and data security principles for health information, including computer-based patient records, standard guides, as I mentioned, on access provisions to health information, standard guide for individual rights regarding health information, standard guide for training of persons who have access to health information, standard guides for amendments to health information and provisional standard specifications for audit and disclosure logs.
ASTM really took to heart the draft regulations and the concepts there and had tried to write standards or in the case of our technical security standards, pulling together a security -- information security standards that could be used. We did not go out in a vacuum and write some of these standards.
What we did was we took some of the standards that were existing, for example, digital signatures, which was also an ANSI NNS(?) standard and put in the requirements for use in health care, like minimum key links. We did not go back and reinvent the wheel. That was not our intent. Our intent was to look at the industry and apply what was done out there and only write standards for things that were involved in the health care industry.
We have about 300 people that looked at these and I was actually involved in the health care work. Also we talked to our friends and colleagues and other people in the industry to find out what was really going on and what we really required. It was not done in a vacuum. It was done with the representatives from HCFA. All our committees that have made most of the moves have been involved to present that point of view. These are consensus standards and they are to help solve these problems.
In most cases, unless a specific thing was required, it is identified requirements. What is the requirement and I liked what the lady over here said. While PKI is the only thing right now that moves the majority of these standards, the whole idea in writing this was to make it as requirement-based and as technology-neutral as possible so that an ongoing technology as it came along or other ways it could be done and the one thing that I think that is very nice about HIPAA, the one thing it looks at is the combination technology and procedures and people.
Let's face it, security is not done by just putting some sort of application on an IT system. Security is a state of mind and while ASTM has been looking at this as a state of mind, we have written all of our standards based on that; that is, a combination of people procedures and technology.
I forgot to thank the board for letting me testify. Sorry.
DR. COHN: I would like to welcome Dr. Gunther Schadow. I think you have come a long way from Indianapolis today. We know you have been trying to get here since this morning. We do want to thank you.
We were trying to figure out when to ask you testify and if it is okay with the rest of the panel, maybe we will give you pause to testify and then we will resume the questions. Is that okay with you?
Welcome.
[Brief recess.]
DR. COHN: Dr. Schadow, we will let you make your presentation and we will go back to questions, inviting questions from the audience afterwards and then we will after that go into our internal -- after that we will go into our discussions. But, please, if you would proceed.
MR. SCHADOW: My name is Gunther Schadow and first of all, I apologize for messing up your agenda. There seems to have been a problem on the Washington side.
Who am I? Most of you probably don't know me and I am working in a next generation Internet contract with the NLM. My part of this project is security and public infrastructure using next generation Internet methods.
I am also the co-chair of the Secure Transactions Special Interest Group in HL7 and the Orders Observation Committee in HL7. In HL7 I have been working on many things. One of those were to secure HL7 transactions and recommendations that were based on Internet standards. I have also worked on the health care information model of the HL7 standard organization.
I am probably not very good, you know, tied to what has been said before because I don't know what has been said before. So, I just looked at the questions you are interested in getting answered and I put together what I thought may make sense.
Digital signatures, it is sometimes treated as being the gold standard to electronic signatures. Digital signatures are strong in theory because they are cryptographically assured accountability so there is a provable method behind the signature.
The problem, however, is focused on the key management and that means you have to -- you probably know how digital signatures work. There is the public key and the private key and the issues are keeping my private key secret and for you to know whether my public key is really my public key. These issues are a real problem in practice. Both of them are.
Everyone who deals with PKI knows that the public key issue is a problem. How can you prove that the public key is really -- and managing the binding of people to public keys, but in practice, it is even the private key compromization problem.
To make an example, I had a verified certificate under the name John Doe. The point here to make is not to say verifying has bad procedures. In fact, everyone who would have read very carefully the statements made by verifying about this public key certificate would probably know that they don't testify for my name, but they did just testify for my e-mail address.
But the point is that we must understand this digital signature and PKI system very, very well in order to make good judgments about what actually is said by all this technology. The other is that trust does not scale very well. There is one company that deals with the entire -- what actually can they authoritatively tell about me.
There is a lot of intermediary stuff involved, like registration authority, notary publics and the system gets very overheaded and probably reacts very slowly to incidents that need to have quick attention, for example, if we are hiring an employee who violated against security regulations. We want to have him enrolled under certificate revocation lists very quickly.
The third issue here is that authority cannot be outsourced. If our institution certifies our own employees, then there is no one who knows better about who our employees are and aren't in our own institution. So, the authority by which we assign these certificates cannot be outsourced. The technology might be outsourceable, but the authority can't.
Probably my biggest point here is that because public key infrastructure is a very hard to manage problem, we should be looking at reusing conventional and local trust structures where they exist. Now, in our industry's PKI progress we are actually trying to do exactly that. We are trying to integrate PKI into an existing management system and making as few changes as possible.
So, we are reviewing our existing management technology, which was the user database. Every medical record system has a user management database with all the passwords and access rights and so forth. So, we are just expanding that to include information about public keys and so forth. We are using the organization and personnel, which is our local MIS department. They have always managed the user -- our user access rights and they will continue to do so, even with public keys. So, they will kind of become a certification authority.
We will also keep and hold on to our existing policies, which is that we require a counter signature from the supervisor of an employee. We are requiring that employees show up in person and the MIS department to sign their form and get their stuff right.
So, we are at arms' length to the process with or without the PKI technology. The other point is that is a PKI certificate is only good for our purpose and our purpose is access to our medical record system. We do not accept shopping certificates, but only the certificates that we have issued in our process. We have disclaim every warranty for other purposes. I will tell you in just a minute that maybe some certificates won't even contain the name of the certificate holder and they do not want our certificates to be used for any other authentication purposes, other than filing onto our electronic medical records systems.
Now, what about these localized structures and why they make sense in health care. First of all, health care is not just another e-business. But, in fact, health care consists of a lot of personal and really physical and rather long term relationships, very different from web-based shopping or these kind of things that typical public key technology is designed for.
The doctors, for example, see their patient in person. I mean, for a physical examination they have to. And telemedicine is probably very far down the road to be really worried about that at this point. So, when it is about to giving patient certificate to access their record if that is their design and it is not at this point in our institution but it may well be very soon. So, if the purpose is to give the patient the access rights to his records and there is no better way to do that than doing it in an actual patient encounter.
The other thing is state authorities license health care professional. So, in health care we have others licensing in accreditation business that exists already. All we have to do is to enable this with PKI technology. And employees get to see their employers. That is what we talked before and, of course, also payers have contracts existing real world -- contracts with providers and so what I am telling you that based on these real world relationships we can add certification and PKI technology without really changing the trust structures towards like a centralized public key authority.
What this makes necessary is that it gives us more multiple specialized PKIs and don't be worried about that. So, we can have a registered public key infrastructure that deals with registries and police and in addition to that, the state board of health in Indiana may have a public key infrastructure that deals with state licensed physicians. The DEA may have a public key infrastructure that deals with DEA licensed physicians and -- so, the point is you should not try to make one system that meets all needs, from e-shopping to remote patient care, but we should build small systems with specialized public key certificates.
The other point is when it comes down to practice we have to deal with unsafe implementations. For example, we are trying to use the Microsoft Internet Explorer, as probably many other people are doing when it comes down to healthy key cryptography and SSL and PKCS standards. That is, by the way, one reason why the PKCS standards have been declared as the most important standards in that area because the Microsoft browsers supports them.
But the problem we are having is very serious at the -- the Microsoft Internet Explorer puts private keys at great risk by allowing pretty much anyone to exploit these private keys in an unencrypted fashion. It is completely unnecessary, but it is still so since Version 4.0 of Internet Explorer.
There are three security modes you can choose from. One is no security, meaning everyone can steal your certificate without you even knowing. One is medium security, meaning that you just have to -- you are getting trained in clicking an okay button and still everyone can see your certificate because you clicked the okay button without looking at what you are allowing to happen.
The third mode is even the worst nightmare from the user's perspective because that allows you to enter your password probably every five minutes or so or if it gets really worse on every mouse click. So, there is this good browser technology that everyone has running on his system and we want to use this for an Internet, web-based electronic medical record access and here we are stuck with real world problems.
There are good implementation like Netscape and PGP -- PGPs actually deal with a different thing. So, it is not browser-based security, but still the problem is the market forces have to work with this unsafe implementation. So, the message is that while digital signatures are nice in theory, in practice they may not be so secure.
Now, let's compare this with electronic signatures. I am from Germany and in Germany we have a digital signature law and in Germany we also have the perception that electronic signatures that are not digital signatures are -- there have been several communications to the European Council that have released an electronic signature communication and basically I am going to the point that a German does not want to have electronic signatures any other than digital signatures.
So, there is some reason to that if you take a couple of examples that you may have experienced while working with a new web-based economy. You are asked to enter your social security number to sign your credit card application. You can enter your initials to sign something else. By checking this box, I agree to the following thing, that I have never read.
Of course, I can fax my financial transaction orders with -- we saw this with a tax device and, of course, it is easy to copy my handwritten signature and I actually did this because I didn't want to mess with paper. So, there is a lot of reasonable doubt left with electronic signatures and the point is that anyone can probably forge most of the e-signatures very easily. Electronic signatures on the web are weak.
Now, I have not talked about biometrics, voice recognition, which is also biometrics in this regard. I just say this as a disclaimer. There is certainly a slightly different picture if you put those technologies into the game. However, when it comes to those signatures being communicated over the 'Net, we have to make sure that they cannot just be intercepted and replaced, which you can even do with voice recognition and biometrics.
How does this all affect health care infomatics? Well, it may not health care infomatics so much because in our environment, in our electronic medical record system, we have worked since more than ten years on the basis of an authenticated environment, where people do their transactions. What this means is that we have usually very tacit authentication, which is state of the art and can be made reasonably secure if done right.
So, users are accountable for all of the actions they do in the context of this authenticated environment, meaning once they have locked on, they write an order. It is locked they have wanted this order. So, there is reasonable assurance that, in fact, yes, they wrote the order. So, what happens here is that the local system and its policies and procedures establish the trust beyond reasonable doubt, so no additional token may be needed to underpin the act of signing.
I want to give you a short insight in what we did with HL7, Version 2 secure transactions and recommendations. We used Internet EDI INT standards, which originally were based on sending ITTI(?) messages over e-mail and in addition, then also over HTTP, the web protocol.
We have simply used this to sign individual HL7 transactions, messages, EDI transactions. The problem we run into this looking at the upcoming security regulations and also I had a small glimpse into the FDA regulation here -- the problem is that with EDI transactions, it is not necessarily individuals who know or are aware about those EDI transactions being sent. What happens is that a physician may write an order but there are also actions like admitting a patient that happens on the user interface and then sometime later may trigger EDI transactions that are being sent between the systems.
So, now if the requirement goes that only that digital signatures have to be placed by individual persons, then we get into trouble because the individual person that triggers the transaction is not aware of the communication and so cannot actually sign because he isn't aware. The only entity that can sign is the system, the computer system, but the computer system is an agent of an organization who run those systems.
So, what we should generally allow is that organizations have organizational digital signatures that they can apply on those transactions. So, what happens then is that individual accountability is tracked within a system, within an electronic medical record system and that accountability between organizations can be tracked between those systems using digital signatures.
This is just a way to illustrate what happens here, to systems with users on those systems. When a user does a certain act, like writing an order, there are messages sent to another system, in this case, might be a pharmacy system showing that basically copying that action over to that other system. Now, the accountability is linked to the system A in case and not directly to the user. What this means is that this user who might look at this transaction may know the name of this user here, but he doesn't really care because all that counts in this transaction is that it comes from System A that somehow trusts it because of contractual relationships between those organizations running their systems.
So, in case someone takes an issue with a transaction, whatever that issue might be, he can contact the system or the organization running that system that requests a problem may be forwarded to some administrative user here, who can then look into the locked files and contact the user who has originated that transaction.
To show how this would look like with non-regulatory accountability, if that -- the accountability to this transaction would be linked directly to the user, to the user who has originally triggered this transaction. The problem this raises is that User 9 in System B may not know even this user in that other system. So, all he cares -- still most of what he -- the User 9 cares about is that this User 1 is an agent of the organization who runs the System A.
So, but still people are now asked to -- so, every individual is now asked to know another individual and that this can only be done with a global public key infrastructure that entails all this big management problems. By the way, in most real world cases, a user, someone in another organizations taking issue with the transaction originating from the first organization will still have to go the organizational route to track down the problem.
This illustration shows you that what happens if every user needs to have relationships with every other user. It gets pretty hard to manage mess of individual relationships and that is -- that can be thinned and made very easily tractable if we recognize that there is accountability between organizations that kind of works as a proxy for the accountability that individual people have.
This model can actually be implemented today because the accountability within the systems is in health care, in most electronic medical record systems already implemented, using the passwords and locked files and accountability between organizations can be implemented, using digital signatures, even without a PKI, using contractual relationships and the exchange on that basis.
The last thing I want to show you is a little glimpse in what we are up to in Version 3 with regard to digital signatures. One problem we have with the digital signatures when it comes to health care information is that we need to know what the signature actually means.
The way we have it in electronic medical records which says patient has fever and this statement is signed by someone, so what exactly does it mean? Does it mean that this someone has made the observation, that he has seen or has become knowledgeable about this observation from someone else or did he just record or transcribe the observation?
In Version 2 of HL7, we did not look into this problem because we said that the system signs the entire transaction. In Version 3, we tried to also allow representing individualized and specialized accountability. The way this would work -- the way this works is that we are generally saying that conceptually acts are being signed and one example of an act may be a medication order for morphine-containing medication.
Then to every act there are certain participants bound to -- one would be the author or an order, the ordering physician. There may be verifiers and other approving signatures. Now, we simply stick the signature into our conceptual information model as one field -- the signature text, that is one field, just like not in the real world where you have a form and there is one line where you have to sign. So, conceptually we are dealing with a signature in this way. But we are adding to that a technology binding to existing standards like the XML digital signature that can then actually implement this signature in terms of a digital signature, but we can also allow electronic signatures in this same field.
So, we are technology neutral in that regard. I think I will not go through the summary but rather stop here in favor of time and thank you for your interest.
DR. COHN: Thank you.
Agenda Item: Discussion
I think we are back to questions and discussion.
Kepa, did you have something you wanted --
DR. ZUBELDIA: Not yet.
DR. COHN: Other questions from people around the table? Dr. Greberman.
DR. GREBERMAN: I was interested in your comments about telemedicine. Some of us believe that telemedicine is moving. Do you have plans for the future when telemedicine will be more active?
DR. SCHADOW: I didn't say that telemedicine does not exist. What I was saying is that telemedicine -- teleconsultation between an individual patient and a physician would probably not replace the arms' length physical consultation in the very near future. If there are telemedical consultations, then they -- in fact, in our grant project, we are doing telemedicine but it happens in a relationship between institutions. A patient is in an institution and will have a teleconsultation from there. But I doubt that the telemedicine from a patient's home without any other person involved, other than the patient and the doctor, will happen very soon.
DR. GREBERMAN: We are seeing a lot of that. I will talk to you about it later.
MR. CRUMPLER: I would add to that. I think that that is going to be happening very, very quickly in the next several years.
DR. SCHADOW: Can I -- excuse me -- I wasn't clear about what this meant. I did not want to say that telemedicine does not happen or it isn't important. The point is that telemedicine will still be imbedded in a system of physical relationships between people.
It is not something that will happen in the way that we go shopping on the Internet, where we don't know that web site. We just go there and place our transaction, put in our credit card number and that will be it.
So, that is the point, that the anonymity will be in the patient/physician relationship very soon through telemedicine.
DR. COHN: Yes, Suzie.
MS. BURKE-BEBEE: The model that you said at the end where it is an institution to an institution, A to B, rather than all the lines showing the individual authentication, is that the model that your institute plans to use outside of your own health care network? How do you authenticate another health care provider or organization that isn't within your own health care network?
DR. SCHADOW: We have electronic exchange of medical record data requires -- for very practical reasons requires a contractual relationship with another organization that sends that kind of data and if for no other reason than because the interoperability of medical information standards is not as good as we want them to be yet.
So, because you cannot go just pluck and play, you have to have some contractual relationship being, you know, out of end relationship. Now, given that no existing system, at least that I know of, would give you individualized digital signatures on every health care transaction, what are you going to do in practice? The only thing you can do in practice is rely on the system security, use a name password and lock file and have contractual relationships between the business partners exchanging the data.
So, it is basically the only way you can implement these things at this point in time on a large scale.
DR. COHN: Kepa, go ahead.
DR. ZUBELDIA: Gunther, I am a little confused. It seems like everybody is talking technology independence, technology independence. In fact, you showed that transaction of a morphine prescription that can have either electronic signature or digital signature so you are not tied to one technology. But on the other hand, you say that HL7 is using EDI INT(?) for securing and signing the transactions and that seems to be a very well-defined technology, open technology, open standards, very well defined and very well -- technology independent where the interpretability problems would be minimum.
Where is the balance between achieving interoperability or achieving technology independence? What do you think we should do here?
DR. SCHADOW: It is a difficult problem. One thing that has probably not become clear is that the working with the EDI INT standards is more based on the existing HL7 Version 2, this open conceptual framework with the signature attributes that I showed you in the last picture is the upcoming Version 3 of HL7.
Now, how do we balance? Well, first of all, we make sure that that is the point from which all of HL7 Version 3 work product standards are developed. We make sure that we don't mess technology dependence into our conceptual reference information model and the definition of the transactions. That so far works to the good.
What we then do is map the conceptually defined transaction messages, abstract syntaxes if you will to what we call inplementable technology specifications. So, what happens is that we have two layers. One is the technology independent layer and the other is the technology dependent layer. We are working on both fronts because it needs to be done. Otherwise there is no interoperability without that technology.
So, yes, you have to decide at some point what you support, but at the same time, you can be open in allowing the support for other -- for new technologies without having to change your conceptual model.
DR. COHN: I actually find what you did to be very interesting and I am actually -- follow up pretty well within an institution. I am actually sitting here and I am just thinking about the work that Patricia Good and Steve Bruck are doing with DEA in developing an infrastructure to allow for electronic transmission of prescriptions for controlled drugs.
Now, I can understand how your model sort of works if I getting a history, if I am getting something down to the pharmacy in my institution, if it is all within the institution. Now, I would image that people in your institution would want to have the opportunity if a patient were, for example, leaving the hospital to send prescriptions to their choice of pharmacies, wherever in the city or wherever potentially in the state, I would think. I would presume that sometimes those would be controlled drugs.
Explain to me -- does what you say have anything to do with that or is that a whole other PKI infrastructure with a whole different set of passwords, access codes, inputs, et cetera, et cetera? I mean, is there any overlap here or are we talking about multiple different PKI infrastructure that don't interrelate in any way?
DR. SCHADOW: I think we are talking about multiple different public key infrastructures that -- there may be some interaction between them, like, for example, the way the prescription management works now is that they want -- the pharmacy wants to know the name of the physician and his state license. Okay? So -- if it is not about controlled substance -- if it is about controlled substances, they want to know the DEA number.
So, just as they are now asking for these numbers, for these license numbers, we can simply -- if all these existing licensing structures are underpinned with digital signature or PKI technology, we can -- instead of just giving them the number, we can give them the certificate. So, yes, multiple public key infrastructures can definitely be done. The point is that the technology that is required to do the public key infrastructure is not that hard to do. What is hard to do is managing all these various relationships between people and these trust structures. So, it is probably not a big issue to have two or three or four certification authorities that certify for very specific purposes. That is much easier -- the technology is much easier to handle than the trust structures.
DR. COHN: Thank you.
Steve.
MR. BRUCK: I guess my comment would be when you think about this topic of conveying identity and conveying credentials. You have a number of problems that you need to solve. I think what Gunther is talking about is a situation where you are simplifying some of the technology aspects of the implementation by transferring that into a situation where you are developing these contracts between different organizations.
So, when you think about prescriptions, how many separate instances of contracts that you have -- I am not thinking about multiple iterations of the same contract. I am thinking of a permutation here. So, thinking about this whole question from a very practical perspective, it seems to me that there is a benefit in looking at technologies that would reduce the number of contracts.
Really what we are talking about here is trust in these transactions, in PKI, in the banking industry, in any heavily regulated industry today that relies on what we have, web signatures. That is a very contract-based world out there. So, it seems to me that you would want to look at technologies that -- you know, I would say this. I would say if you compare the complexity of the contractual problem with the complexity of the technology problem and apply Internet speed to that entire equation, you would have a case to say, well, gee, if there is money to be made here, it seems like somebody is going to solve that problem.
With digital signatures, particularly from DEA's perspective, we are looking at solving two separate and distinct problems. Now, all of that is being said under the context of one contract, one certificate policy that would govern the entire operation of this system. So, we don't have a situation where Pharmacy A needs to have a conscious decision, needs to make a conscious decision to trust Health Care Organization A or Health Care Organization B. We have a situation where we have one contract and we have a situation where the digital credential satisfies two specific needs that are important to DEA.
That first need, which is very obvious, is that need for integrity because if you look at what we have today, it is paper based and it really is biometric based. If you were to classify all wet signatures in use today as biometrics, that is what we have and that doesn't solve the problem that we have today with fraud. What we have heard loud and clear is that very often -- no, that is not true. People do change prescriptions. Right? You get a prescription for 10 Percocet, it is very easy to change that 10 to a 70. Okay. The practitioners wet signature doesn't guard against that alteration.
So, from DEA's perspective, there is a strong need for message integrity, prescription integrity. But there is another requirement; that is, to know that the issuer of that prescription is a DEA-registrant. Okay? So, when you think about this whole topic of trust and trust in a transaction, typically, you focus purely on the information. That information is digitally signed. I know that information hasn't been altered, but you also need to consider, and you have probably talked about this this morning, that a practical implementation of such a protocol would require that the digital certificate be sent along with that transaction.
So, you have a situation there where the credential is signed by a trusted third party. The pharmacist can make an immediate decision, local, the pharmacy, about whether or not the credential that accompanies this transaction should be trusted. The information in that digital certificate would provide the pharmacist with enough information to make the kinds of decisions that the pharmacist should be making.
There are other alternatives to that technique. I am just thinking practically here. When you think about credentials, in my mind I think about an issuing authority. When you have DEA registration that comes from DEA, if you have a -- when I go to the doctor, I look for the certificate that has a seal from the medical college that my practitioner went to. So, you are always looking for the guarantee and that is what that digital certificate provides you.
I would make the argument that you need to for a practical perspective, look at both of those requirements simultaneously. If the certificate doesn't include credential information, then it seems to me you have a separate problem and that is how do I get credential information. Okay? I have a digital certificate. Perhaps it accompanies the transaction. That gives me enough information to identify that individual. Where do I go to find trusted credential information.
I am not thinking about just a generic database with perhaps populated by the organization, but should that information in the database be digitally signed? I think that is a valid question. From another practical perspective, how many transactions are required in order to build enough information so that you as a relying party have enough information to make a trust decision because from our perspective what we are faced with is a pharmacist has to make numerous decisions. Today they don't have the tools to make those decisions.
You have to figure out has it been altered. Has the prescription been altered? Is the practitioner a registrant? Does that registrant have the authority to prescribe this particular range of controlled substances? There is a whole range of different trust decisions that need to be made and if you look at message integrity separate and apart and ignore those other trust decisions, then I think it is easy to make a case that says, well, gee, maybe we don't need a digital signature.
But if you look at then in their entirety and I think that is the way you need to look at them, you would come to the conclusion that what we have here is credential-based work flow. What we would like is that you don't go
-- is that the credential -- the electronic certificate or whatever is passed along with the transaction provides that level of trust, not only for the identity but for the credential.
DR. COHN: Thank you.
Jan, did you have a comment?
MS. LOVORN: There is another feature of a PKI that we haven't really talked about here but you are bringing up, the idea of this contracts and relationships between organizations. When the digital signature and -- the 509 certificates were originally thought about, this concept came up a lot in the discussion. When they came out with the newest version of Version 3 of the certificate, there is a lot of policy information in there or policy information. What happens is when we are writing our standards and looking at stuff for writing it with certificate policies, a CA when it issues it will probably come up with some sort of contractual obligation with its subscribers and that can be short hand by using what they call a policy I.D.
For example, all the pharmacists in the state are registered and they will be operating under a certain policy and that could be identified. Then when the doctors get their licensing and things, the companies would be at cross relationship and that might have another policy.
So, when the doctor writes a prescription at the end of that, there will be certain things in the certificate that the organization has put in there that says, yes, this doctor is operating in our offices. He is okay. He is credentialed. So, let's check this.
So, at the other end before the pharmacist, the physical pharmacist ever gets it, the system has looked at this identifying information. So, the computers that are not validated will not even get to the pharmacist. He doesn't have to go back and check, oh, is this a valid pharmacist, a doctor from, say, Kaiser Permanente or Columbia Health or some medical program. If the system is already going to check that against identifying contractual shorthand that is there, that is one of the neat things about this technology, while it is not -- it is not technology neutral, but it meets that kind of requirement, will allow you to do this all in the background without the Dr. A, who is signing the prescription.
All of that information is going to be sent along with his request to the pharmacist and the pharmacist system will check this information and then the prescriptions that need to be signed, they will pop up on his window and he didn't have to do anymore checking. The system says "yes." Pharmacist, please fill this prescription for this amount so I can verify the amount and verify the drug, as we all know is a problem with physician signatures and that we know that this is a practicing physician.
If that is the case, if for some reason this fails, then there is an audit trail to go through here because all of this stuff has been audited at every point, then we can verify that this person somewhere in this process somebody was lying.
I just wanted to bring that out, that that thing had been thought about not just for health care but for other areas because it is really important that you don't have to go check all of this stuff. I mean, let's face it, what we are looking at here is the ability to do -- I kind of like to think of digital certificates as my driver's license on the Information Highway.
As we all know, there are restrictions on our driver's licenses, whether we have to wear glasses, are we going to drive at day or at night. Kind of as a shorthand, that is what I like to think of as a digital certificate, which digital signatures is only a piece of the implementation and features that certificates and the PKI provide.
Thank you.
DR. COHN: Thank you, Jan.
Panel, I want to thank you very much. It was a wonderful panel. I know you have all come from significant distances, Dr. Schadow, spending the day probably trying to get out of Indianapolis. I really want to thank you all.
We will stand up and take a five minute break and then we can come back together.
[Brief recess.]
DR. COHN: Dave, did you make a comment or two?
MR. BARNETT: This is Dave Barnett from Kaiser Permanente.
This morning when I started, I was pretty clear on what all the issues were and what a digital signature versus electronic signature and I think the first place we need to start is definitions and requirements. We need to at least agree on these things. I don't care what someone defines electronic signature is; just tell me. I will go along with it. I don't care. As long as we can agree on the same thing and what a digital signature has to do, what the requirements are. I think that is a great start.
Then we can start drilling down to, okay, here is what it is and then here are acceptable ways of implementing it, knowing that the technology is going to change and start getting into the details as it gets very complex. So, we need to know where to break it off. But right now, I think we are all scattering off in different directions. Kaiser is implementing a PKI. DEA is implementing a PKI.
Shine(?) is implementing a PKI. The CMA is implementing a PKI. We have all these things that are going on at once and, of course, we all know that a route CA is the best way to deal with it, as Kepa can testify. We all have our own routes.
Already we are in trouble. So, I am feeling tremendous time pressure to get some organization and guidance here so we can start converging in the industry because I think we are headed for a real problem, a very expensive problem unless we start narrowing the field to things we can understand.
I noticed today a lot of the discussions got down to very technical details. I wanted to jump up sometimes and say but wait that wasn't -- that won't work, but I think that is an inappropriate level for today. First we need to agree on the higher level things like what are electronic signatures, what are digital signatures. What are the frameworks that are appropriate for them that are necessary in health care.
I got confused with like going up and down the levels. In particular, authentication mixed with digital signatures. Now, obviously, we need some kind of authentication to make a digital signature mean something. You have to know who did the signature. But in some ways that is a separate area. There is something you know, like a password or something you have and this could be a private key, a token. Finding what an appropriate authentication mechanism is and how you bind the person to that authentication is a slightly separate issue from digital signatures. We have to do that before the digital signature means anything.
I would break up the identification and authentication mechanisms and definitions, requirements from digital signatures. It is a separate issue. One way these things mix together is we are implementing the PKI and we are also looking at biometrics. PKI is normally authenticated with passwords and a private key, which is something you have. You could also implement it with a biometric, something you are, in addition to a private key. So, there are ways to mix these things.
Jeff, I think you had a question?
MR. BLAIR: Yes. We are winding up saying that we need to agree on the definition and the requirements and the procedures. Is that correct?
MR. BARNETT: These are the most critical areas.
MR. BLAIR: Can you suggest instead of us, you know -- we don't want to become a standard development organization ourselves. So, can you suggest a good place for us to start with that?
MR. BARNETT: I think there are areas that are worthy of investigation. ASTM has done a lot of work. They have a model policy, which is currently in draft stage. It is not quite done. But it is something. It is some place to start with.
The American Bar Association has done some work with defining digital signatures. IEEE 1363 defines digital signatures. You have got the X9 series. We have got the Phipps 186. There is a lot of work that has already been done clarifying these. I think a review of the literature and pick something that, first of all, breaks the definition of a digital signature from any kind of technology that implements it, define it in terms of requirement. I that has already been done in places. We just need to cut and paste from things that have already been done.
The requirements and definitions really need to be agreed on before we can proceed further. Otherwise, we are just scattering all over the place. That is a big concern because we are spending a lot of money on PKI and I see other people are doing that as well. These won't work together and may not even be an acceptable solution unless they start converging very quickly.
DR. COHN: Dr. Schadow, do you have a comment?
DR. SCHADOW: I wonder whether this is practical. The problem is -- it seemed that the answer was that to Mr. Barrett's question about isn't there anything out there. Yes, there is. In fact, there is so much out there, it is like it is -- the saying fits perfectly, that the good thing about standards is there are so many to choose from.
So, in fact, I believe that this is what the Department of Health and Human Services did when trying to write the regulation for security. They went out there, got all this stuff and then tried to make some sense out of it. Well, so far, they have done not too bad of a job, I guess, but it is very, very hard work and then in the end, what did get out of this. You have then written yet another framework of how these things can be done.
So, I don't think that this is really the road down to the practical implementation and also I would even be worried about different organizations making different PKIs. What really counts, what is really important is that these digital signature efforts combined with the other information interoperability standards -- because what you really want -- you can digitally sign electronic information. So, what you first have to have is the electronic information. So, you pick a standard, like HL7 for communication with labs and stuff, like NCPDP for communication with pharmacies and then pick that organization and both something that works with these standards, I guess. That is really an important thing, rather than -- the problem with all the security stuff is that there are people who do nothing else than security, but really what we need to work on is where the rubber hits the road or where the medical information standards need to be secured.
MR. BARNETT: I wasn't really proposing more standards. We have enough. As long as we can get some agreement -- the digital signature is probably a pretty good start and the HIPAA NPRM had some fairly decent material in it. Right now I just see all the confusion. I mean, like today was a good example of it. I don't think that it is okay for too many PKIs to start proliferating because the interoperability is going to be very much of a problem and cross certification.
I think it is great the DEA has a route. So do we. Too bad we couldn't get together earlier because we do our own clinical information systems and getting to electronic prescriptions. It sure would be nice if we only had one certificate that could do all that. Now, we need to get something into the DEA route and -- has been proposed several times to us by several agencies and you only do it once. So, I think the time pressure is very critical. We need to get some clarity here very quickly.
DR. ZUBELDIA: In kind of addressing that, we are going to hear tomorrow from Richard Guida with the Federal PKI Bridge(?). It may address how those multiple rules can be bridged together maybe in a multi-weighing(?) bridge and they can work together.
But what I haven't heard today is about a standard for digital signatures, even though we have talked about the electronic signatures and digital signatures and PKI. I haven't heard about a standard for digital signatures, which seems to me odd. There is a standard for certificates and all sorts of certificates. And there is a standard for certificates. But then when we go to use the certificate as digital signature, then there is an HL7 way of dealing with EDI INT. There is XML ways to do digital signatures. There is PKIX digital signatures. There are all kinds of different ways to do the digital signature itself.
So, not only do we have the certificate level and the trust level and the policy level and the CA level, we also have interoperability problem on the digital signature itself as a standard. I don't know if there is something that can be -- even if we chose to go PKI and digital signature. Now, with biometrics, it is a little worse. It looks like there is no standard in biometrics.
So, I don't know even if we could find a solution to this. I am not sure.
MR. BARNETT: Well, I think we have to start somewhere, like Phipps 186 is a good place to start. Because right now everything -- there are no standards. Nobody agrees. So, let's not, you know -- so, we can't do anything I think is a bad approach. We need to start --
DR. SCHADOW: There are standards. You just listed them. I mean, there PKCS7. That is purely digital signature standard. There is PKIX profiles for the stuff. So, in fact, there are standards and, again, there are just many standards and the problem is that these standards do not really tie into the information -- the medical information communication standards that exist out there. There are standards for everything. You just have to bring them together. That is the problem.
MS. GUGEL: I represent a PKI vendor. I am with Baltimore Technologies. Unfortunately, I am the only PKI vendor here. But the standards are very important and we do have a number of them and what is important for the vendors to do is to implement all of those standards, even if they are conflicting. Sometimes we implement more than one standard even if they are conflicting and give the user the choice.
So, that is how we can implement these different standards. When I first started working for Baltimore, I was thinking how can you do that. Then I realized, oh, we give them a choice. They can turn around and say I want to use this standard or that one and we give them lots of choices in algorithms, choices in certain type of protocols for certificate management or another conflicting protocol. Those are standards that are completely mature and it is very clear which direction they are going to take.
That is a challenge for the vendors.
DR. BRAITHWAITE: This comes back to the thing about standards. There are so many to choose from. It doesn't make any sense to me.
MS. FRAWLEY: Just going back to the question about standards, you know, as Jan pointed out in her testimony, ASTM has a number of standards, you know, in this area and they incorporate by reference, you know, Phipps 186 or a number of other standards. You know, I made my disclaimer before about my association with ASTM, but, again, I think that people need to take a look at those standards because when Jan -- when Peter was originally chairing the subcommittee and then Jan and Rich Actne(?), the thing that we were very careful to do was always make sure that we were incorporating whatever was out there from ANSI or from Phipps and to make sure that we were putting together that, you know, would, you know, develop a framework that we would need.
So, you know, as I said, I know there are five ANSI accredited standards in this area. One of the is on digital signatures and we have the guide for electronic authentication of health care information. There was the framework for the use of electronic signatures, Internet-Intranet. I mean, there is a number. I know you can log on CST and web site and get access to all of that information. But I do agree with Dave's comments is, you know, that we have gone around in circles today and I think that it is important and I know, certainly in my work at ASTM, we spent a lot of time just on definitions because when we first came together as a group, people didn't understand that a physician could be signing a document in many different capacities. He could be signing it as the attending physician. He could be signing it as the consultant. He could be signing it as the supervising teaching physician.
You know, he could be signing as the person who declared the patient dead. So, there were many different capacities and, therefore, you needed to know what the user's role was. But just in terms of coming up with, you know, definitions and then trying to lay out requirements, it took us about two years on the first standard, which was the guide for electronic authentication of health care information, you know, to talk about the fact that there needed to be multiple signatures and the fact that if, you know, a document was amended, you know, how you would handle all that because a lot of work has been done out there, but I agree with Dave's point that I think we have to start making sure we are all on the same page in terms of, you know, what our definitions are, what our requirements are and approach it that way because, you know, I have done a lot of work in this area and when I am sitting here, going I am getting confused and I thought I understood this, you know, and the other thing that I think is troublesome to me this afternoon is the fact that we have got all these different groups going out and doing different things. I mean, to me it is very troubling to hear that the DEA is going off on this project and we have got, you know, the provider identifier that will be ultimately coming out in, you know, an NPRM and we have got, you know, the FDA with their requirements and we have got, you know, the state boards going out and doing different things.
I don't know how we can stop for a second and say, wait, everybody stop, you know, and how can we all get together.
DR. COHN: Yes. I made a quick comment to Kepa, because I think we are sort of in the same situation we were a couple of years ago with the HIPAA administrative simplification regs. There is a reason why those things were passed back in 1996 and there is a reason why they mentioned electronic signature. We are probably at a point where we probably need it. I think we are sort of seeing that there is going to great expense if we don't assist in this one.
Kepa.
DR. ZUBELDIA: Simon, that is exactly what I was going to talk about. I think that this is a strong sense of deja vu. It was four years ago that we were discussing UB92 and NSF and X12 and UB92 and NSF were in the standard way that people were doing it, but it wasn't standard. It was just non-standard.
The X12, it was more like a framework that would see ASTN and IEEE standards -- it is a framework that can be implemented in different ways. It depends on how you implement it, it may or may not interoperate. Maybe what we need to do is stop looking at the standards because there is too many standards to choose from and actually start looking at specific implementations of the standards and recommend specific implementations and the same as we have specific implementations of specific transactions and we have A37 -- and say, okay this is the specific implementation of this ASTM framework that we have in health care for prescriptions. This is the specific implementation of the ASTM framework that we work for medical records and let the standard setting organizations that developed these frameworks define the specific implementations so HIPAA can adopt specific implementations of signature mechanisms to be adopted for health care.
I think that EDI INT, for instance, it is a standard. The vendors, at least two specific implementations that I have seen that implement the standard in a very well-defined way and maybe that is the way to go on. Take those discussions one level beyond the standard and getting to the specific implementations to be adapted by the Secretary for specific purposes because, like I said, there are plenty of standards. I don't think we will gain anything by having one more formula collected by the department.
DR. SCHADOW: I agree, but I think the key is to say for a specific purpose. If the issue is about HIPAA and supporting -- securing claims transactions, then pick something that works well with X12 because that is the work horse of these claims transactions for HIPAA. In fact, X12 has a digital signature specification on their own, as far as I know, and look at EDI INT or whatever and then pick something that actually works rather than just being the framework that does not have an implementation.
However, I would also that this can only be done if the project is well-scoped, if you are not trying to do health care digital signatures. That is just a far too big project.
There has been attempts in the banking industry to do such a thing to mandate specific standards, the government mandating specific standards and there have been interesting -- on those hearings from the industry. I don't think it is appropriate for the government to say we define the one health care standards to do all health care security and, again, I wonder why you are so scared about DEA doing their thing. I think that is great and that is exactly what needs to be done.
Whoever has authority over a certain issue of licensing and however this currently interacts with the work flow, like DEA numbers being used to authenticate and authorize certain drug prescriptions, then that organization can pick something that works for the existing work flow in the existing environment and make up their own PKI. I don't see where the big problem is there because you don't have to use DEA certificates for any other purpose.
MR. BARNETT: I agree with Kepa's approach. If we get down to some detailed specifications that will the interoperability forward quite quickly. I have been trying to be technologically neutral, but if we give that up and start specifying things, we can really move very quickly in this area in interoperability and getting things working. There are some advantages to that.
DR. ZUBELDIA: Let me be a little specific. For instance, X12, X12.58, that defines security structures for X12. Most translator companies have implemented in some form or another. That is something that could be specified for X12 transactions, use X12.58. Another thing you could use for X12 is like EDI INT. That could be specified.
NCPDP for the prescription uses -- syntax, that also has a 9735 implementation of security for messages. That could be specified for prescriptions. HL7 has a prescription message. That could be specified using EDI INT or it could be specified using XML signatures.
In the electronic medical record, it is important to keep track of changes in all of this. Maybe XML is the way to go. So, I am not saying one way. In fact, I am saying may ways but as long as they are well-defined for this specific application and well-defined implementation guides, then we would have a sense of interoperability for that vertical side of the health care at least treated or clinical message. Maybe that is the way to go.
MR. BLAIR: This is less of a comment than -- really a question. So, Kepa, you could probably clarify this and I don't know if the answer has to be today or anything, but it seemed to me as if in the last ten minutes, we were beginning to pull together a direction. Kepa, you seemed to have articulated it, which is if we looked at a framework and it appears as if -- and maybe if we all get a copy of the ASTM specifications and we read it, we could validate whether, in fact, that could be the framework.
You were winding up saying -- and I think, Gunther, you were winding up saying we need to go further than just a framework. We need to make sure it is implementable. In that case if that does, in fact, prove to be a useful framework or if we find that it is short of being useful framework, then we have to enhance it and maybe some of the specific implementations might be able to show that we can enhance it. Maybe if it is a good framework, we could begin to map the specific implementations against the requirements defined within the ASTM standards.
Is that essentially what you were thinking of? Am I hearing you correctly?
DR. ZUBELDIA: Jeff, what I am thinking is that ASTM has drawn a lot of the security experts in the health care area to agree into a framework that is expressed as guidelines or guides, whatever, that we work in health care -- I think most of these frameworks, like the Phipps 186 series and the rest, they have 80 to 90 percent overlap. The one that is the most specific to health care is probably ASTM. We have the standards and we have the experts. Let's give those experts the charge to come up with implementation guides of their own standards that they have developed, the same as happened in X12 and then once those experts develop those implementation guides, then they could be adopted. But right now there is no implementation guides. All there is is a framework.
I think that the ASTM has probably the most complete one. The only argument I have with the ASTM framework is that it is very strongly related towards the Internet and today almost a negligible amount of the transactions happen on the Internet. So, they need to seriously consider an application to non-Internet health care and once they do that, I think -- I don't think the framework would have to change. I think the implementation guide would have to allow for non-Internet transactions and it is something that could be adopted.
DR. SCHADOW: ASTM has obviously written a lot of good contributions to that matter. We need to make sure we understand what we are talking about specifically. There is the framework, the security framework, which is a very good document and there is also a provisional standard -- I don't know the number, but it is about digital signatures in health care.
Now, while the framework is very good, the provision of standards for digital signatures in health care is very concrete, actually implementable. There are definitions for all these structures that are proposed there. However, the problem is with this standard, while it is implementable, it does not really interact with any of the existing information standards that are out there to convey electronic information that needs signing.
So, all they have in their signature standard is to talk about a document and that document is basically whatever it is, text data or -- certain signature purposes being attached to it. The other problem is that they are so heavily -- it is not very friendly and probably not modern anymore to implement. So, if it is about having a concrete specification, then I would be cautious with the digital signature standard, much rather looking at the XML digital signature specification.
So, just when it talks about ASTM there, there are very good documents but I would be specifically careful with a digital signature in health care provisional standard.
DR. COHN: Comments?
MR. CRUMPLER: If I could say something about what this is like. This is not unlike what the computer industry was like about 15 years ago. Whenever you had an IBM flavor and you had a DEC(?) flavor and you had a number of other vendors, all of which were thoroughly incompatible with one another, had totally different ways of looking at the world and had different ways of implementing what they did.
I don't think that the solution that you are looking for in terms of a standard exists today because you have all those different flavors of implementation. In thinking about what happened to get us from the main frame world to the PC world and the interoperability that we have today, there was an intermediate step and the intermediate step was where we had translation protocols going from one platform to another. We had to go through that translation process first before people said this is stupid. Why don't we just have interoperability.
So, they then developed a whole new set of standards based on interoperability, but we didn't get there directly because all the vendors were in competition with one another or they had vested interests in terms of their particular implementation. The same is true for a standards organizations. They have vested interests in what they put forward. They are pushing that -- they are pushing their own particular approach. So, I don't think that you necessarily have what you need to do. You might have to go through an intermediate step in order to get there.
DR. ZUBELDIA: Let me make a comment that from what I have seen and from the experience of interoperability pilot that last year, I was coordinating, the security vendors want to sell a health care market and they are trying to sell to a health care market. They will do whatever it takes to sell to a health care market.
They really want to know what is the health care market going to buy. And the health care market has no idea what to buy because there are so many -- and they are waiting for HIPAA to come out and say this is what -- so, once HIPAA has final rules and says this is how digital signatures work, this is how encryption works, the health care market will say this is what we are going to buy.
Within nanoseconds, the security industry will have something to offer.
MR. CRUMPLER: This is exactly the experience we have had with our Part 11 implementation. The industry is affected. So, you don't want to buy until we know that what we are going to buy is compliant and the people who are providing the solutions aren't going to produce it until they have customers to sell it to.
So, it is a sort of a catch-22 and you are in exactly the same situation.
DR. BRAITHWAITE: We are in a slightly different situation in that HIPAA requires us to adopt industry consensus standards, not make them up like the FDA did. People expect HIPAA to be the horse and, in fact, we are supposed to be the cart, according to the law.
DR. ZUBELDIA: We are getting whipped anyway.
DR. COHN: Other comments?
I feel like we are sort of at a point where we closing off any of these options. That is a very complex set of pieces and I think we need to try things on for size. Certainly, I am hearing that there needs to be, I think, a fair amount of more understanding of some of -- competing standards, the options that we have. People talk about ASTM, but I don't have a strong conviction really of what is there versus what isn't there. I don't know how much it has been implemented. I would feel that way about almost -- about many of these other standards. So, we probably need to do some analysis to get a slightly better feel for all of that.
But we also need to try it on for size. We will be hearing people tomorrow. We can sort of maybe talk to them about this issue because I mean what we are seeing here is going, well, gee, should we get pretty specific or should we stay general. I mean, certainly the secured NPRM was very general. Should we get specific? Would that be of help? Would that work?
If we are going to do it, you know, how do we go about doing it in a way that doesn't saddle us with a full time job doing this for the next year, year and a half? That may be identifying something that looks good and telling that -- standards groups very often create implementation guides and that may be an option. We had better make sure it has a good foundation. I hear one person saying that is pretty good, another person saying, well, gee -- a little more opinion in the room, as well as a little knowledge of this to see if there are some ways that we can sort of forge through to a consensus.
DR. BRAITHWAITE: I agree with you, Simon, but I want to make one thing very clear that the reason that the HIPAA adopted standards for transactions works is because we adopted extremely specific implementation guides. The reason that we were able to get away with adopting general language for security is that more interoperability requirements were involved.
With digital signatures, it is only about interoperability. We cannot adopt general standards for digital signatures and expect people to implement them, in my opinion. We have got to have very specific implementation guides that will guarantee interoperability or we will just have another one of these general philosophy studies in what digital signatures ought to look like.
DR. SCHADOW: I think it is very doable project as long as it is well scoped. So if really what you want to do is to have digital signed HIPAA transactions, then that is not hard to do. The choice even is easy because then you either picked the X12 security wrappers or you pick whatever Kepa comes up with. Whatever you pick, just go ahead, do it, but be clear about that this is not the general health care way of doing it once and for all, but it is just -- it is just like picking X12 was, I believe, the way I interpreted, very pragmatic, this is something that is out there. You can use it. It is not that X12 is the end of the line and the design of information interoperability messaging or stuff like that, but it is there.
So, pick something that fits well with X12 and then go ahead and do it. Then the industry, like you say, will jump on it and implement it. I would just be cautious about declaring this as the health care -- maybe it is going to be used for other areas, but that I wouldn't try to get in all health care and all governmental agencies to jump on exactly the same standards because then it is just so hard to agree.
DR. COHN: Maybe I will try to answer that when I am through. Kepa probably has a comment. I agree that the scope is always important and we can look at digital signature for all -- I was impressed when the FDA talked about a single digital signature activity for 25 percent of the GNP. I doff my hat to you.
The problem of trying to constrict too narrowly is if you look at the HIPAA regs and you see upcoming HIPAA standards or looking at claims attachments, which are -- I guess are X12, but they have HL7 contents in them. You have other standards that have to do with administrative simplification, which we haven't even defined yet and certainly you are seeing HIPAA having a fair amount of impact on the Internet. So, it needs to cover all Internet transactions, which -- not X12, but has content for -- it is the coefficient of data content on the Internet for purposes prescribed. So, once again we are beginning to expand the scope a little bit.
We need to start somewhere but it is clear we need to be a little more expansive than just asking X12 what they are using and then we go home.
Kepa, do you have a comment?
DR. ZUBELDIA: Yes. The scope issue is a very important issue we need to consider. Right now, none of the HIPAA transactions require signatures. So, to have a standard for X12 digital signatures, whether it is X12.58 or anything else, it is an exercise in futility.
From the business case that we have heard this morning, maybe prescriptions need signatures and medical records need signatures and prescriptions -- there are two kinds, the pharmacy uses Elefact(?) messages, Elefact syntax. Well, Elefact has security envelope that applies to Elefact messages.
The other kind is HL7 signatures for prescriptions and I understand that HL7 already has either EDI INT or XML for signatures for HL7 messages. So, maybe those are the three ways to go for signatures because those are the only business cases we have heard that actually need signatures. Anything else, sure, you can use signatures but it is not as a signature. It is a security mechanism. So, if you need to use a security mechanism with X12 transactions, maybe you can put in X12.58. Those are security mechanisms.
For signatures, all I have heard today HL7 or prescriptions. I think that those two groups -- maybe we need to use those for those specific purposes for those prescripted scopes.
MR. BARNETT: It is an interesting thought. I mean, if we narrow down the scope of things to very specific kinds of transactions or narrow requirements, then we could probably come up with something that is detailed enough and implementable in a time frame and that might be very useful. Medical records, of course -- electronic prescriptions are very interesting. Some of the transactions perhaps -- I think that that is something that could be done. I think we are getting technology specific, which isn't necessarily a bad thing because trying to move at Internet speed is very difficult and just trying to agree on a common language about these things may take years.
To have one implementing in time frames of like three months, as happens to a lot of our internal projects, we need to move fairly quickly on this before things get -- I mean, they are already out of control but before they get worse.
DR. BRAITHWAITE: I was just going to agree with Kepa. I think focusing our attention and focusing the attention of those standards groups that can produce implementation guides, if they have not -- and the business case errors that we need under HIPAA that we can adopt and then examining the ones that have been produced and encouraging them to make them more specific as we did with X12 to the point where they are implementable and interoperable. I think that is definitely the way to go.
MS. TRUDEL: I guess my question is do we develop standards for digital signature for prescription outside of developing a standard formatting content for that prescription or are those two things part and parcel of the same activity and the same for the medical record?
DR. SCHADOW: They are not the same but they are very related and you should always start with a standard that represents the prescription best. So, if you start with -- if you pick a -- I am from HL7, but if you pick NCPDP, then you have picked NCPDP and now you put the security wrap around that that fits NCPDP best. Maybe it is that or it may be EDI INT because, in fact, this EDI INT specification has been built for -- for X12 and for HL7.
That part is not hard. I believe Clem McDonald's group will have told you the same thing in the past probably, that the standards for the medical information are much harder to do than the security standards. So, once you have your medical information standards, putting the wrapper for the digital signature around it is not that hard.
MS. FRAWLEY: We really need to be careful and limit our scope of work to a standard for a digital signature because the standard for content of the medical record would involve an analysis of 50 state statutes and regulations, all of your accreditation on standards because you have different types of health care facilities that are licensed and accredited by different organizations and it would be extremely difficult to come out and define, you know, the content of the medical record. I think what we are talking about is affixing, you know, a signature and I think that is where we need to focus because we would be, you know, sitting here for years to come trying to define, you know, what each organization, you know, will -- based on its location and who it is accredited and licensed by to come up with their own, you know, requirements.
I think what we are talking about is if we want to move towards computer-based patient records, what can we do to help the industry in terms of affixing a signature.
DR. COHN: Certainly the computer-based patient record and medical information is part of the PMR work that Jeff is doing and has written 60 pages and still hasn't come to the answer of what are the medical information is there.
One of the things that we will talk about tomorrow is as we begin to talk about new standards and all that is a prescription standard something that we should be looking at as a new standard coming down the way and we somehow need to take that into account as we are looking at all of this. But certainly this should be a separate piece of work and if we allow it to be intertwined, we will never get anything done in terms of all of this.
Something to think about is, obviously, Kepa was positioning -- one of the things we want to listen for tomorrow especially is are there any meanings that we just didn't hear because we weren't asking that specific question. Let's cross all the sort of the standard domains and transactions that you may have or plan to have that need digital signatures. That may be something we need to go back and look at but we will also get some of that information tomorrow as we listen to some of the people who have been doing digital signatures.
This is sort of the first discussion as we try to evaluate what we have heard today. I guess what we hear from everybody is that is general agreement that let's get as specific as we can.
MR. BLAIR: I didn't know that we had all come to agreement. I thought there was a couple of possibilities of how we might proceed here. I think the only thing we seem to have agreed on is the need for some type of standards for digital signatures. I think that, you know, from what I have been hearing, there are a couple of different approaches, but I thought -- I didn't hear that we had come to a focus on how we would proceed yet.
DR. COHN: We have been sort of worried about whether we stay at sort of a very high level framework, not be very specific about what level it is we are going to be trying to move to or -- trying to drive that scope down as opposed to just a general framework and kind of high level recommendations.
Am I misrepresenting what anybody thought? Okay. Good.
Kepa.
DR. ZUBELDIA: Gunther said something that keeps coming back to me and maybe I knew this but it wasn't in the front of my mind. He said EDI INT can sign -- I think that is important. I think that if we have something that can be used immediately, even before there is a prescription message, even before there is medical records standards that can be on experienced with for securing X12 messages, that don't strictly require signature, but the same structure can be used for X12. Maybe that is a good candidate. I would like to encourage EDI INT to work together with ASTM and see if it fits the ASTM model, see if it fits the ASTM framework. If it does because EDI INT already has specific implementation guide that can be tested for interoperability and there is a process to test for interoperability. Maybe that would be a candidate first standard and maybe later we can look at other standards, like XML, that may be very applicable, but maybe that is a candidate and can be used now for standard transactions knowing that it can also be applied for Elefact messages with prescriptions and HL7 messages, too.
DR. SCHADOW: You are right and it is not only that there are implementation guides, but there are so many implementations of it already for sale. I have some contact with a company called Cyclone Software or something. They are always asking give me a customer in the health care market and we will work with them and it doesn't pay for them to implement the entire thing. All it takes for them is to just, you know, take what they already have, which is already tested with other windows for interoperability and just apply it to HL7 with a real interesting customer or apply it for -- it can be easily applied for NCPDP, as far as I know.
It certainly fits an ASTM framework document. It does not fit, obviously, the ASTM specific digital signature standard, but that is not too big of an issue, I would think. So the frameworks are certainly -- someone could go check it.
DR. COHN: Thank you. That is something we need to investigate further in terms of that but it is an interesting piece.
It is 5 o'clock now. Do people have final comments or -- we will be starting at 8:30 tomorrow morning. I hope everybody will be bright and shiny.
We are adjourned for today.
[Whereupon, at 5:00 p.m., the meeting was recessed, to reconvene at 8:30 a.m., the following morning, Friday, October 27, 2000.]