[This Transcript is Unedited]
Hubert Humphrey Building
200 Independence Avenue, S.W.
Washington, D.C.
Agenda Item: Call to Order and Review Of Previous Day and Plan for Today - Dr. Cohn, Chair
DR. COHN: Good morning. This is the second of two days of hearings by the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics. We will soon be moving into our fourth and final panel of these hearings.
I want to start by just going around the table and introductions of everyone.
I'm Simon Cohn. I am the chair of the subcommittee, and a member of the NCVHS, and National Director of Health Information Policy for Kaiser Permanente. Also by way of comment, I should probably disclose I am an employee of Kaiser Permanente, and have, to my knowledge, no conflict in terms of any of the hearings or testifiers today.
Jeff, would you like to?
MR. BLAIR: Sure. My name is Jeff Blair. I'm Vice President of the Medical Records Institute. I am vice chair of the Subcommittee on Standards and Security, and a member of the National Committee on Vital and Health Statistics. And I made my disclaimers yesterday with respect to testifiers.
MS. FRAWLEY: I'm Kathleen Frwley. I am Director of Health Information Services at St. Mary's Hospital in the state of New Jersey. Yesterday I did indicate that I was a member of ASTM from 1993 through 1999, and participated in the development of many of the standards that we discussed yesterday at E31.20, which is the subcommittee that addresses electronic authentication, digital signatures, and security at ASTM. And also E31.17, which is their privacy and confidentiality subcommittee.
As many of you know, I was employed by the American Health Information Management Association, so I have, during some of our comments yesterday, referenced the work the AHIMA has done in areas related to retention of records, contents of records, and so forth. And I think that covers all of my disclaimers that I need to make.
DR. FITZMAURICE: Michael Fitzmaurice. I'm with the Agency for Healthcare Research and Quality. I'm government liaison to the National Committee on Vital and Health Statistics, and staff to the Subcommittee on Standards and Security. I have no obviously conflicts of interest, because I work for the government. I want to take all this good information that these people who come from the private sector give us, and do good things with it, to help make data more uniform and comparable.
MR. LYNCH: Good morning. My name is John Lynch. I'm Vice President for Research and Information Services at the Chime Trust, which is an affiliate of the Connecticut Hospital Association.
MR. GUIDA: Good morning. I'm Rich Guida. I'm Chair of the Federal PKI Steering Committee under the Federal Steering Council. And I'm also an employee of the Department of the Treasury, so I don't think I have any conflicts. My Treasury stock options have not yet materialized.
DR. NEUMAN: I'm Sherry Neuman. I'm a clinical pharmacist with a company that has developed hand-held technology for prescription applications. And I have no conflicts of interest either, but I do have stock options.
MS. BURKE-BEBEE: I'm Suzie Bebee. I am a Health Informatics Specialist with the National Center for Health Statistics, and staff to the subcommittee.
DR. ZUBELDIA: I'm Kepa Zubeldia, a member of the committee. I'm starting a new company called Clarity, and there is nothing I can announce about that yet, because we don't have a business plan yet. But as you know, I worked until a couple of weeks ago for ENVOY Corporation. ENVOY is a member of ENTICA(?). And while I was at ENVOY I participated in the ENTICA PKI project, and some other ENTICA projects. I'm also a member of ASTM E31, although I've only been to one of their meetings. And a member of X12, and I chaired the interactive prescription in X12 until the last meeting.
MS. TRUDEL: Karen Trudel, Health Care Financing Administration, staff to the subcommittee.
[Additional introductions were made.]
DR. COHN: Before we start the panel, I'm going to make one panel, and then Jeff wanted to make one comment to expand on his disclaimer statement.
[Administrative remarks.]
Jeff, would you like to make a comment?
MR. BLAIR: Sure. I really think this is a very good practice, the disclaimer. I kind of gave a narrow one. Let me give a broader one. I'm also a member of HL7. That's a standards committee for anybody listening on the Internet that might not be familiar with it. Another standards committee is the American National Standards Institute Health Care Informatics Standards Board. I have been a member of that for about five or six years, and have been on the executive committee of NCHISP(?), a member of AMIA, American Medical Informatics Association, and HCIMSS, the Health Care Information Management Systems Society.
DR. COHN: Okay, does anybody have any other disclosures or disclaimers? Okay.
With that, why don't we launch into our panel, which is really a report on the existing projects, both private and federal. Our first speaker is actually not here at this point, Holt Anderson. Hopefully, he will arrive later on this morning. With that, Richard Guida, are you willing to start out?
Agenda Item: Report on Existing Projects - Richard Guida, Federal PKI Steering Committee
MR. GUIDA: Absolutely. Thank you very much, Dr. Cohn, and let me mention by starting off that I very much appreciate the indulgence of the panel. It's an honor to be here this morning. I was scheduled to originally be on a panel yesterday, and you all very considerate in allowing me to do it this morning instead, because I was at a conference yesterday in North Carolina, explaining what the government is doing to a group of folks there. So again, I very much appreciate your indulgence.
What I'm going to do this morning is give you a brief picture of what the federal government is doing with respect to public key technology. And in particular, what I would like to do is discuss what we are trying to accomplish in the way of interoperability. I realize interoperability of PKI has historically been a challenge, but I think we actually have a fair amount of progress that I can report on about ways in which to make disparate PKIs work together. So I think that's something that I hope will be of interest to you.
The other thing I want to mention right off the bat is there are a number of statutes of course, many of which are aware, HIPAA of course being an obvious one. But there are other statutes the federal government operates under with respect to the use of any form of electronic signature.
The most important statute is a statute called GPEA, the Government Paperwork Elimination Act. GPEA basically says that federal agencies will accept electronically signed, electronically formed by October 2003, subject to certain provisos -- more than 50,000 copies a year, to the maximum extent practical, those sorts of things.
Now in that statute, the statute is technology neutral, by which I mean it allows for any form of electronic signature to be employed in the placing of an identity onto a document. The important thing to understand, however, is that even though the statute is technology neutral, that does not of course mean that all technologies are created equal, at the risk of stating the obvious.
If you look at the implementing guidelines that the Office of Management and Budget has put together, has put out to agencies, those guidelines recognize a spectrum of different ways to make signatures, ranging from PINs and passwords, to the so-called shared secret approaches, to the stronger cryptographic mechanisms of digital signatures in the use of public key technology.
What the guidance also recognizes is sort of two points. One, you, meaning the agency, need to decide which technology to employ that is best suited to your application. If you need strong authentication, then you use a stronger mechanism. The stronger mechanism is the public key technology, the digital signature.
But in addition to that, it also recognizes the value of interoperability. The issue here boils down to we all live the death of a thousand PINs and passwords. We would very much like to avoid having unnecessary credentials. What digital certificates allow, what a PKI allows for is the prospect at least of having fewer credentials, and having them have utility or usefulness across a broad variety of applications.
The issue is if I have a credential, I have my Treasury Department ID, can I get into the Pentagon with that ID? No, I can't. The interesting thing is neither can people who have National Security Agency IDs. They can't get into the Pentagon either.
So the point is you would like to have a credential that has some utility beyond your own little narrow sphere. A digital certificate offers that opportunity as long as you have a way to interoperate PKIs. So I'm going to talk about that in particular, because we do believe that we have a mechanism to accomplish that.
Now what I'm actually going to do here is let me start if I could by talking about the latter. We have a think called the Federal Bridge Certification Authority, the FBCA. The Bridge is basically a way to make PKI work interoperably. In simple terms, if I want to make two disparate PKI domains work together, I have two things I have to accomplish.
First, I have to do what's called policy mapping. That is if the two domains have disparate policies, one issue is the X, Y, and Z certificates. The other issue is the A, B, and C certificates. And the nature of these certificates is described in the certificate policy. The certificate policy is placed in the certificate policy extension of the certificate, each certificate that is issued under it.
So in essence, you know when you are presented with a certificate, under what circumstances was the certificate issued? How strong was the identity grouping done before the certificate was issued? How strong was the cryptography in the certificate? Where is the private key protected? Is it on a hardware token? Is it in software? Where is it protected?
So you have to first, if you want to interoperate, agree upon a mapping. And the mapping agreement is accomplished by virtue of the policy bodies that are responsible for these disparate PKI domains getting together and deciding mutually on a peer-to-peer basis, what their exchange of currency is, so to speak. How many pounds is a lira worth? How many liras is a pound worth? This is literally what you have to do.
Now once you have established what is called policy mapping, that gets placed into what's called a policy mapping field of the certificates that exists between the two domains. You don't have to put that policy mapping information in each individual end user certificate. You simply express it one place, and that one place is in the so-called cross-certificate between the two certification authorities that constitute the tops of the local domains.
Now in order to make this work then technically, you need a way to process that information, and in a larger universe, where you have a lot of different CAs, you need a way to tie all those certification authorities together in a fashion which does not result in a mesh, or a mess, as one might say. A mesh meaning if I have 15 CAs, and I want to tie everyone together, I have 15 x 14/2 connections, 105 connections. That's a lot.
So what we have come up with is an approach called the Federal Bridge Certification Authority. The goal here is I have a single node or a single hub I should say. And the hub is the Bridge. I cross-certify all the different spokes of the wheel as it were with the Bridge. As long as I have a relationship with the Bridge expressed in a cross-certificate with that Bridge, and somebody else has a relationship with the Bridge likewise expressed in a cross-certificate, I have topological connectivity.
I have the ability to establish a trust relationship between my domain and any other domain that is connected to the Bridge. Now this is a concept that we have been working on for several years. We actually were able to make it work in a prototype form in February-April timeframe of this year. We are now in the process of building a production version. What I'm going to describe briefly is what we did.
As I mentioned, the Bridge is in essence a non-hierarchical peer-to-peer hub. It support interproduct and interdomain interoperability. One of the nice things about the Bridge concept is we do not require a specific product. We are basically open to any product that a user wishes to employ. What this means is that inside what we call the Bridge membrane we actually have multiple products. And we make these products work together within the membrane of the Bridge.
If I'm external to that membrane, then as long as I am either using a product that is expressed in the membrane, or I'm using a product which I know interoperates with something that is inside the membrane, I am clear to use whatever I wish. And by and large, as you will see, the products we are talking about are the mainstream products. These are products which are well known.
Now the prototype that we developed for the Bridge started with two products.
MR. BLAIR: Excuse me, for my benefit. If those major products are displayed on your graph, I can't see them.
MR. GUIDA: I'm going to state them.
MR. BLAIR: Thanks.
MR. GUIDA: No, sir, I understand. I promise you I was going to exactly state them. Besides, they give me a royalty every time I say their names. I'm being facetious.
The two products are Endtrust and Cybertrust, initially. This is what we started with, with our Bridge. You build a nucleus. You have to start with at least two proton, or a proton and neutron or whatever. But the nice thing about this is we can add additional products inside the membrane, and we do intend to do that in the production version of the Bridge.
We intend to have about six CA products inside the membrane for the production version. But for the prototype we started with two, Cybertrust and Endtrust. We used an X500 directory product. Peer Logic was the directory product.
Our goal in making this Bridge, and in trying to do this Bridge and test it was we wanted to try to bring together two disparate PKI domains through the Bridge. In essence, one domain would cross-certify with one node of the Bridge. The other domain would cross-certify with the other node of the Bridge. Inside I've got the two nodes cross-certified, so that's how I achieve my connectivity.
In practice, we were able to do much better than just get two domains working together. We got five domains working together in the span of under two months. Up here we have a chart, which let me describe. This is a chart of the actual test that we employed successfully in April. What you see here is in the upper left-hand corner, the Bridge itself, which is the Cybertrust and the Endtrust certification authorities.
Then connected to them are six different PKI domains, five of which we were able to actually get working within the two month time frame we had to work. We would have gotten the sixth one working too, but we just ran out of time. You know we had a year to do this. So what happens? You have ten months to spend to get agreements in place, the lawyers satisfied, the Treasury Department to get its carrier pigeons to deliver the money to the agencies, and then you have two months to do the technical work, right? Okay.
Connected to this, what we have is the General Services Administration had one of the domains, the National Institute of Standards and Technology actually had one domain, but two different certification authorities, one connected to each node, because we wanted to provide some interesting way to do testing.
We had the Georgia Tech Research Institute, so we actually had a state agency involved. We had NASA, National Aeronautics and Space Administration. We had the Department of Defense, which had their own very rich topology. They had their own Bridge test. So we actually here connected two Bridges together, the DOD Bridge to the federal Bridge. Underneath the DOD Bridge we had three separate other PKI subdomains, two were hierarchical, using Spirus(?) and Motorola certification authorities. One was a mesh using Endtrust certification authorities.
And then finally, the thing I was very excited by, the government of Canada. They cross-certified with us as well, and they participated in this test fully. So that was the nature of what we sought to test. The client that we used, we tested e-mail. We were using S-mimed(?) e-mail, and we actually used Eudora, and we used Microsoft Outlook. These were out of the box products, but we also used out of the box plug ins for both of these products, as well as some custom designed plug ins, because these products out of the box don't do what is called certificate trust path creation and validation. We had to add some stuff in to be able to make them do that.
The good news is the stuff we added in is like I say, either available publicly for free, or available from the vendors. And moreover, this capability is becoming available both through Netscape and Microsoft out of the off-the-shelf products. Microsoft it's part of their Whistler Windows 2000 release; Netscape as part of some Java aplets they are writing for their browsers, which will do trust path creation.
Now the participants -- I already listed those participants.
Now let me describe the results. What we tested was s-mime connectivity. We basically sent e-mail messages from one domain to the other. So here I am. I get an e-mail digitally signed message from a Department of Defense client. From a client software operating under DOD hierarchy. And over here I'm in NASA. So do I recognize this certificate? No. It's issued by NASA, but I'm in DOD. So of what value is it to me?
What the software did was it created a trust path. It literally created a trust path of cross-certificates from the domain of the relaying party to the domain of the issuer. And then a process of that trust path to make sure that the certificates have not been revoked, to make sure they were still valid.
When we tested this functionality, we tested functionality in both directions. We looked for false negatives, false positives. We actually tested certificates that had been revoked. We tested certificates that were outside of the domains entirely. We were looking for evidence. We weren't simply saying, well, if it worked one time, whew, we're done. It's all good. We tried to do a fairly rigorous test.
What we discovered was that we were able to make in the span of literally two months, most of the transaction paths work. I have a chart up on the board which shows roughly 60-70 percent of the transaction paths were working within two months. Some of the transaction paths have a deb in them. By that we mean debug. Those were transaction paths which were not working at the time we had to demonstrate this in April 2000.
It turns out that two weeks after we demonstrated this, we discovered the reason why those paths didn't work. There was a single bit set incorrectly in one of the cross-certificates that we had established. Once we corrected that bit, we were able to establish these other paths working as well.
So in essence, we had 100 percent success in making all of the trust paths work, with the only exception being the one domain, GSA, which we just ran out of time and resources to make work within this context. So I can claim complete success for five PKI domains operating within the span of a little over two months. This actually was more of a success than many of us expected to be able to experience.
So the bottom line is what we like to portray this as is the Bridge concept worked. It works on a peer-to-peer basis. This particular test did not test what we call policy mapping. That is being tested today actually, in a follow on effort which we hope to have operational within the next month or so, working with the Department of Defense. DOD is actually doing some exclusive work on this.
Policy mapping, where I can literally take certificates from one domain, and establish just their quality in my domain. Not just establish that there is a path, but establish their quality. Now the interesting thing is the 90 percent of the hard lifting was done here. Establishing trust paths was the biggest challenge. Once you can establish a trust path, processing that trust path is straightforward. I won't say trivial, but it's straightforward.
Because in the trust path you have the policy mapping information. So the big thing is can I establish a trust path? Can I create it? Can I discover it? If I can, then I most assuredly can do policy mapping. And that's what we are demonstrating in a furtive follow on test right now.
So what it all boils down to is this. I have got agencies issuing certificates to their employees. I want to be able to have those certificates have broad utility. I want to have other agencies be able to accept them through the production version of this Bridge, which we hope to have operational by the end of this calendar. We are of course in the death of a thousand continuing resolutions right now, but assuming we get past that point, we hope to have it operational by this year.
We would like to be able to have each agency be able to accept certificates issued by other agencies to their employees. That's the goal. And that is in essence peer-to-peer interoperability. There is no global route here. No agency has to subordinate itself to some other agency, which is an anathema to a lot of agencies, and for that matter to a lot of entities.
We do not operate on the basis of a route. We operate on the basis of peer-to-peer. Your trust banker is your route, and God bless you agency X. That's your route of trust, your anchor of trust. So this is how we are planning to interoperate.
Now beyond that -- yes, sir?
DR. COHN: Were you going to move on to the next slide?
MR. GUIDA: Yes, sir.
DR. COHN: Would you do me a favor then and read the fourth bullet, and explain what that means, as well as the fifth bullet?
MR. GUIDA: Yes, sir, I apologize. Some of the things we discovered was that directory interoperability is critical to PKI interoperability. What that means is I've got all these wonder cross-certificates. I've got all this certificate revocation information, and usually in the form of certification revocation lists.
Unless the client software that is creating and processing the trust paths can discover the cross-certificates, the CRLs, all that information, it can't process this. It can't make it work. How does it discover that information? It goes to its directory.
Well, if its directory doesn't contain the information, what does its directory do? If it is X500 in chaining, it goes out into the big, bad world and gets the information. If it is LDAP(?) with referral, it gets a referral and goes out and looking for the information elsewhere.
So in the final analysis, directories have to work together to share information, or you've got to keep in your directory, all the information you need to interoperate with all of your trading partners. One of the two things has to happen. Now that is not as big a problem as it might seem. Directory interoperability has been something that has been worked on very hard for many, many years, and there is some success to report.
We did X500 chaining. We actually used X500 chaining. We made five different directory products work together with X500 chaining, which was also to some of the people, more of a miracle than making the PKI work together. But it worked. It actually worked magnificently.
Now directory entries must line up with the certification authorities. Once again, it's an issue of you have to have consistent schema. You have to have consistent DITs, directory information trees. You have to be able to know where the information is stored, how the directories are populated with this information to be able to obtain it.
And as my final bullet says, lots of details, so there are lots of devils. The devil is always in the details. This is certainly the case here.
Now for the production Bridge, let me mention one final thing. For the production Bridge, because Baltimore Technologies, as most of you are probably aware, purchased Cybertrust, the production Bridge will have Unicert, which is the Baltimore Technology certification authority in the membrane rather than Cybertrust. And that was a deliberate decision that we concurred with 100 percent, but a decision of Baltimore Water to put Unicert in.
So the production Bridge first two nodes of the Endtrust in Baltimore. The other CAs that are likely to put in, but I can't tell you -- it's not my decision to make, it's the decision of a lot of people -- will include CAs from Netscape, Microsoft, RSA Key On(?) Spirus. Probably I'm going to upset somebody by forgetting them --
PARTICIPANT: Verisign?
MR. GUIDA: Verisign possibly, although interestingly Verisign has told me that because RSA Key On will probably be in there, Verisign interoperates with RSA Key On. So you don't have to be inside the membrane. If you interoperate with a product that is inside the membrane, that's good enough. The only reason to be inside the membrane is bragging rights, which obviously is important for some companies. So this is how we are in the process of constructing the Bridge.
Now the body that oversees the operation of the Bridge is the thing called the Federal PKI Policy Authority. That now exists under CIO council. It came into existence in July of this year. It has met twice. It is getting itself organized to be able to accept applications from agencies to interoperate with the Bridge.
We have a certificate policy for the Bridge that has four levels of assurance: rudimentary, basic, medium, and high. It's very close to the Canadian certificate policy. Why? Once again, we want to be able to interoperate with Canada.
So my point is all of the pieces on the policy and technical level to make this happen are coming into existence. And we are trying to do it in parallel fashion, rather than do what government sometimes does, which is serially. We would like to do in parallel.
So I thank you very much. I have a lot of other things which I would be happy to answer questions on in terms of the strengths of the different technologies. When I advise agencies on the use of digital signatures versus other means of making signatures, I try to make sure they understand that the greatest strengths usually come from a combination of the technologies.
But if you have to pick a single technology, and will not be a surprise when I say this, but if you pick a single technology to authenticate yourself or to make a signature, I would pick digital signatures, because it is a cryptographic mechanism to impress your identity. It does provide for data integrity. The same infrastructure can be used for confidentiality, as well as for a signature, and it provides a firm basis for non-repudiation.
It doesn't not guarantee non-repudiation. Nothing guarantees non-repudiation, not on the earth at least. So in the final analysis, PKI is the best single solution. But I'm not contending that it is the only solution, nor am I contending that it would not be improved through the use of other technologies as well.
My personal view is the use of biometrics to unlock your private key generated and stored on a hardware token, and used on a hardware token constitutes perhaps the strongest way that we can do identity proofing and signature manufacture today. But that's something which obviously is not ubiquitous yet.
I thank you very, very much for your time.
DR. COHN: Richard, thank you very much.
Holt, welcome. Would you like to go next?
Agenda Item: Report on Existing Projects - Holt Anderson, NCHICA
MR. ANDERSON: My name is Holt Anderson, and I'm the Executive Director of the North Carolina Healthcare Information and Communications Alliance. And I will also be talking from the perspective of the HealthKey five state project, funded by Robert Wood Johnson. And I want to start with that.
The HealthKey project is a five state alliance funded by Robert Wood Johnson. The original of HealthKey, this sequence goes back to the fall of 1999 when the Robert Wood Johnson Foundation awarded a $2.5 million grant to this collaboration to advance the development of health information infrastructure, and in particular public key encryption infrastructure.
We are attempting to do a market-driven, community-based approach to these projects. And we are coordinating pilot activities in all five states.
One of the first outputs was a set of two documents, "Recommendations and Guidelines for Community-based Testing," And "A Framework and Structure Process for Developing Responsible Privacy Policies." And this is available on the HealthKey website as a download. It's kind of like writing the score of last night's baseball game before the first inning. So we are looking toward trying to prove this through these projects.
The participants include the Massachusetts Health Data Consortium, the Minnesota Health Data Institute, the North Carolina Healthcare Information and Communications Alliance, the Utah Health Information Network, and the Community Health information Technology Alliance in Washington, CHITA, part of the Foundation for Health Care Quality.
Our strategies have been to identify interoperable standards-based solutions to real business problems, real clinical problems. And we want to drive all of our projects from a clinical need to do something that we can apply the technology to solve.
We are going to be showcasing in a pilot, participants as leaders in testing and evolving these health information infrastructure issues as sort of a sweetener to get people to put forth the effort to these projects, which is something in addition to their normal duties of trying to run a clinic or a hospital.
The $64,000 question, is PKI a valid infrastructure for the health industry, and how do we prove that? What is the model? We met with Mitretek about two weeks ago, and I'm delighted that Mr. Guida has presented his presentation prior to this, because several of our members had heard a presentation he made in California I believe, about six months ago. And it started to fall in our minds that perhaps this was an answer to the interoperability issue of PKI in health care.
So we actually got in touch with Mitretek, had a meeting about a week and a half ago. The two states of Minnesota and North Carolina have come forward to say we would like to try it. If everything falls into place, we would like to pilot in real clinical health care situations, and involve multiple CAs in the process as well.
We would like to have some demonstrations up and running by the spring of next year, which is a pretty aggressive schedule, and aligns with the Robert Wood Johnson projects. And then the other three states in the alliance are watching with particular interest in this, to see if we fall on our swords, or if we can actually make it work. And we certainly hope in Minnesota and North Carolina that we don't end up being the fools here.
The projects in North Carolina involve an immunization project that has been going now for about a year and a half, involving the combination of public and private immunization records being accessed through SSL3 over the Internet today. We want to add digital certificates and biometric validation on that in this next phase.
We have two clinical projects that came out of UNC-Chapel Hill. One was a project where there is a neonatal intensive care unit that newborns, and sometimes mothers prebirth are brought into this setting. Then the birth takes place. And these are children that have severe problems. They cannot be cared for in their local communities.
So there is not currently a method of sharing that information with the primary care giver in that setting, except through fax or phone calls. And so the opportunity here is to create a database that we can put accessible, to authenticate individuals in the local setting so they can get the up-to-date information on vitals at any point they want it, inform the parents, and tell them how the child is doing. So there is kind of a clinical need, and a good project here.
And then there is another one that is a similar project for children who have special health care needs. Again, very young children who are brought there to this intensive clinical setting from rural areas. And their parents are obviously anxious and probably can't stay there or travel there every day. And want to hear through their person primary care physician, how things are going. This would allow this kind of access on a real time basis.
And by the way, the clinicians in the intensive care setting feel that this is a good opportunity to train the local physicians, so when the child is brought back to the community, they are aware of what steps they need to take to care for the child.
There is another possibility that was just discussed, looking for a high value application that everyone would understand. And so we started looking at prescriptions, where if a physician can write it, sign it, go directly to the pharmacy benefit manager, and then to the pharmacy, that this would save a whole lot of time and a whole lot of hassle, and is something that could show maybe a return on value. So we looked at that as a possible project.
Minnesota, likewise, has some projects they would like to try with the federal Bridge, and multiple CA zone. They have an immunization data project as well. They have newborn screening results from the Minnesota Department of Health. They want to provide secure access to a central query service for eligibility inquiries, and again, use the Bridge to see if we can get some interoperability among the projects.
And then the other states have various other projects that they will talk about.
The recommendations I think at this point is keep an eye on all the models that are emerging. The HealthKey Bridge Project could evolve into a national infrastructure for health care. And that's being a little bit presumptuous, but we don't see any other alternatives out there to get the interoperability up and running within the two year timeframe that HIPAA is going to require.
We think that getting there in two years is a real challenge anyway. And until we can start spinning out some projects and prove something will work, we don't see many alternatives in that.
And certainly we can't rely on a single vendor. No entity, and certainly no state and no governmental agency is going to look at a single vendor. We have to look at the marketplace. If we've got a plug in that they come into a Bridge fairly easily, without a whole lot of developmental costs, it will encourage others to come into the marketplace.
And certainly stay away from the stovepipes. We've got enough of those. We don't interoperate, and we don't need to continue to proliferate that.
As I say, what I have given you is not part of this handbook, but I do plan to leave this here, because I don't want to carry this weight back to Washington, so I will provide it for staff. I encourage you, if you would like these reports, they are available on the HealthKey website as a pdf download.
Now are there any questions with respect to that before I move on?
DR. COHN: We'll have discussion afterwards.
MR. ANDERSON: The next document I owe the authorship of to my colleague in NCHICA. He was trying to respond to your questions that were posed to Panel 4. Are we using electronic or digital signatures now? Not currently, and we're edging in that direction. We certainly have plans to use these in these projects I discussed, to enable transactions currently performed with paper.
We believe that such applications will reduce cost and improve the timeliness, and possibly the accuracy of the transmittal of clinical data like tests, prescriptions, referrals, et cetera. The use of "good" electronic signatures that have the attributes of non-repudiation, secure authentication, end-to-end assurance of message integrity, and other necessary attributes of electronic signatures is available we believe, only through PKI. And certainly PKI is not widely deployed in health care today, which is one of our issues here.
What do they enable? And I covered that in the answer above.
What are the results of the project? Well, we don't really have reports yet. We need to get them, and get them soon if this is going to be an alternative for us in complying with the HIPAA security and privacy requirements as proposed.
What problems have we found? Well, obviously the big one is interoperability among the CAs, and among the competing infrastructures. It's the primary barrier we see to interorganization adoption of PKI-based signatures. No one is writing checks at this point, because they just don't know that they can use these with their trading partners.
Until that problem is solved, in general, PKI will probably languish as a disconnected set of islands of many PKIs that can provide e-signatures intramurally, but are not useful in the multi-organizational system of US health care.
How can health care and HIPAA learn from our experience? Well, we hope to deploy some in real-life clinical applications in a setting that uses the Bridge CA to overcome the interoperability barrier. We are heading in that direction even before this hearing was announced I think. So we are pleased that perhaps we are on the same path that you are.
We think a successful Bridge CA with consistent directory services would certainly be a giant step forward in advancing PKI-based digital signature use in health care.
How does the E-SIGN Act impact your work with signatures? We haven't studied that act a great deal. I don't know that there is a great deal to study. But what our view is, is that perhaps its lack of specificity in that act can set back health care. Because people are going to think that that's the answer to health care security and privacy, and we're not sure that that has the robustness of infrastructure to allow that to happen.
And there are some additional suggestions there.
North Carolina and some of the other states have existing e-commerce laws related to CAs that we think might be stronger than UCITA.
How would the HIPAA standards help, and how will they help? They specify encryption, but not PKI. They should mandate the use of PKI based on electronic signatures with minimum operating characteristics and attributes to end the fear, uncertainty, and doubt about what constitutes good electronic signatures. There is just not any boundary, and definition out there that we can rely on.
What are our recommendations for the adoption of the standard electronic signatures under HIPAA? We believe that PKI currently is the only technology available to implement good electronic signatures. With a more robust PKI infrastructure, including a Bridge CA for health care, we could see a wider use of additional certificates, perhaps in combination with biometrics identification to activate the user's digital certificate.
Adoption of a standard form factor, such as a credit card-sized or a brass key-shaped token to enable portability of the digital identity would also be useful. In today's health care community there are minimum standards for secure encryption, but no standards for holding and transporting digital certificates for use in generating PKI-based digital signatures. So vendors end up pitching their proprietary incompatible pieces of the pie to anyone who will listen -- that's our opinion of course.
The result is further fragmentation and less interoperability. And there is a little hominy written after this describing a patchwork of cloth that is sort of being thrown in the box and reconfigured and pulled out and patched together. But we don't have a full quilt yet, because no one is coordinating the colors, and the interoperability of all the PKI pieces.
Thank you again.
DR. COHN: Thank you very much. As I said, we will have discussion at the end, after all the speakers have testified.
John Lynch.
Agenda Item: Report on Existing Projects - John Lynch, Connecticut Hospital Association
MR. LYNCH: My name is John Lynch, and I'm Vice President for CHIME Trust, an affiliate of the Connecticut Hospital Association. I thank you for inviting me to testify here today.
I would like to start off with a little bit of a health care scenario, because you are asking how do we use PKI in health care. And start off with a physician in their office, seeing a patient. The first thing they have to do is log on to the system. They identify themselves with a PIN number, password type thing to their application. In this case I'm using an application being a pharmacy application. It could be sitting anywhere, at an ASP, on their mainframe, wherever, but they have to log in somewhere to their application.
The next challenge then is to authenticate who is this person at the other end of the wire? Is it really a physician? The physician they say they are, et cetera? So in our case we are using digital certificates on smart cards. The physician in this case could present their digital certificate, authenticate themselves to the system.
The physician wants to write a prescription. So he can write it in the clear, and according to all the requirements, we know we cannot send it in the clear like that. We want to sign that prescription, and we have to have some layer of trust there. So the physician would in essence, attach their digital certificate to the prescription, signing the document.
It's still in the clear, however, so we need to encrypt it. So what do we need? We need a directory in essence, to find the public key of where we are sending it. So in this case the patient chose CVS on South Main Street in Cheshire. So how do we find that public key to send it to them? We need that directory. One of the things that Rich alluded to earlier this morning was the need for the directory and the linkages and coordination of those directories as being a key component.
Now we can encrypt that document, so on one else can see it in passing. If per chance, like happened up in Boston recently, the e-mail goes out, and it goes off to 50 of the wrong people, at this point in one sense, who cares, because no one else can decrypt it other than that pharmacist it was being encrypted to at the other end.
So the pharmacist now is able to authenticate themselves to their application also with their digital certificate, and can receive that encrypted prescription. Again, no one else can read it at this point. They have to reverse the process, decrypt it. Now they can read that prescription.
But there are still a few steps let potentially here. How does that pharmacist trust that document now? We have to go through a little bit more detail in checking out this prescription. Again, it could have come from Joe Hacker. So we need to validate that prescription, and we can do it in a series of ways.
One, we can validate that nothing has changed in passing. So we have the digital certificate hashing bit that takes place that says if anything gets changed, the number would no longer compute in essence. So we can reverse that process and validate that nothing has changed in passing, like no one has intercepted this document, added a zero to the quantity of drugs. So it is an original document that came from this person who signed that certificate.
Then finally, the final step is to validate is that a valid certificate still as of this point in time? Did that physician perhaps get disbarred or something in the meantime since they originally received their digital certificate? Go off to a value-added authority, using a standard OCSP to validate that this certificate is live, valid, up-to-date, et cetera, and indeed it's a valid prescription. Now we can tender that prescription to the patient.
So that's a little bit of a health care scenario. Now the key component here in my mind is yesterday we were talking about businesses cases for digital signatures. I'm trying to present a business case that it's not just digital signatures, but it's the combination of authentication, identification, encryption, et cetera that is the business case.
You need something that is relatively simple, that works all of this process together. If you are picking and choosing separate, independent components for authentication, encryption, and digital signatures, et cetera, you get into much more of a mesh and a mismatch. And the health care provider wants something that is simple, straightforward, that's going to plug in and it's going to work, and it's going to do as many of these things as possible.
So my sense here is that the business case is really don't concentrate on just the one. But you need to think about how all your other requirements mesh together here. And you have one solution that really handles all of them at once.
That really leads to a whole series of health care requirements. To me, this is another area that NCVHS can hone in on. I think it was mentioned many times yesterday that the key component here is looking at those requirements, and helping to resolve across health care, how to resolve and meet these requirements.
The first one on the list is the chain of trust interoperability across health care communities. The key component here is that a lot of the PKIs today have been these single community components, a single hospital or whatever. It's across enterprise from hospital to doctor to pharmacy to nursing home, et cetera, that is key here, and that we have to establish.
Another requirement, 24 by 7 by 365 reliability, availability. We have tested out a lot of the biometrics for example, and well, they are not always 100 percent reliable and valid. We have tested out PenOp(?) for example for the electronic signature. My signature was never reliable. They didn't trust me, because I didn't consistently cross my T in my middle initial or something.
Now in health care, that's a problem. If a doctor is in an emergency or whatever, and needs to get access to information, they can't depend on a technology that may or may not work. They need it to be reliable all the time. So we need to make sure these technologies are there, and we're not bound by those components.
Another example are some of the options out there that rely very much on central servers in the sky someplace. And if you think about it when Hurricane Thomas or whomever comes along, and the power lines are down, but that hospital is still up and alive and running, and needs to be treating even more patients and everything now, because they are coming in because of the disaster or whatever, where are we if we have to go off to a server in the sky to validate every transaction going on internally in the hospital? So we need other options available.
The enders base, I think we talked a lot about yesterday. Trusted health care route, I think we started getting into some of these issues yesterday with the DEA, the FDA, et cetera. Whoops, are we getting into a whole series of these things? Are we coming up with four or five different ways of saying the same thing, you're a doctor? Is there some better way to come up with a Bridge, a trusted CA, or whatever that will help coordinate that whole process and alleviate the multiple identities?
Professional health care credentials or authority bound to your identity. What I'm getting at here is this is not like perhaps the banking industry where all they care to know is that you are John Lynch. In this case, if we are trying to go transactions across enterprise, hospital to an insurance company, for example, to try to do an eligibility, the insurance company doesn't know much other than the fact that I'm John Lynch. It needs to know that perhaps I'm John Lynch working at Yale New Haven Hospital, and I'm the patient accounts office. Okay, I'll let you in to look at eligibility.
That's the scenario we have with health care, that we have bind that authority. What authority are you acting under in this particular transaction?
Non-repudiation. This is where the digital signatures come into play. A lot of the transactions you have talked about are transactions that don't require a signature. But health care has a lot of actions that do require them. When we get into malpractice issues, et cetera, we need to make sure that we can really have that non-repudiation down lock solid.
Again, getting into an issue here of the centralized, vulnerable storage kinds of issues and back up. I believe one of the things that Rich can tell you about for example, in the federal model, is they are looking at multiple keys for an individual, not just one. There might be a signing key separate from an encryption key for example.
An encryption key you may want to back up into a back up authority in case you lose it, and someone is encrypting a message to you, and you have lost it. Opps, I still need to somehow recover that process. On the other hand, your signing key, and we're talking about digital signatures for that, you don't want backed up in that place where someone else can get at it, because now you are countering that whole non-repudiation issue.
So that concept of the dual keys there for example, the signing key, and the signing key not being stored in the same place, being able to be hacked into, being able to have someone get at their identity.
The signature in essence is tied to various roles and identities. A physician can go between different hospitals. At one hospital he may be the ED physician. In another hospital he may be acting as a consultant or whatever only. He may be allowed to get at different aspects of data. So we need to be able to have those directories again. Rich talked about the directories and coordinating those. At the directories, where a lot of that role component controlled by the owner of that data, available and interacting is a key requirement and component here.
Finally, another key requirement is the mobile identity. A physician might have five offices. Go home at night. Try to get at the lab results, and then go into the hospital and go up to any one of 200 different PCs. That identity has got to go with him. And it can't be necessarily stored on all 300 different computers. It's really got to be mobile with him, because if it is stored on the computer, they are potentially opening themselves up your non-repudiation issue.
One identity, multiple uses. We talked yesterday about having 20 different ID badges. Well, in Connecticut what we are testing out for example is one ID badge issued by your hospital HR department. Instead of just getting your normal plastic ID badge, you get one that's a smart card.
So now it's both the identity you walk around with, your physical security, and can start opening up perhaps your doctor's parking lot, your doctor's lounge. You are not going to lose it now, because it gets you back to your car. As well as now putting in and opening up the computer. Multiple uses like that reinforce the importance of it.
Distinguishing the signature certificate from the encryption, we talked about the multiple components.
Differentiation of identities at different layers. We believe health care has certain major functionalities. One, your employer. A federal component; a lot of what they are talking about are employee identities. We're talking about the same thing in health care. We need to identify that you're an employee of a hospital. You're an employee of a nursing home or whatever, and you have that relationship. If you lose your employment, you should lose your identity, because you should no longer be able to get into that database and pretend you're that employee to get access to Blue Cross' data or whatever.
Certificate validation in real time. A lot of that identity doesn't have to be done in real time, especially if a lot of the transactions are done locally in the hospital. You've got that established in your database. You can trust that. But it's most likely done when you are going externally, and you want to make sure that that identity is real and live.
Integration to legacy systems. We have all these legacy systems out here, and you will see in a little bit how we have been trying to integrate into a variety of other approaches via the Web or via tack on systems that will allow you into legacy systems.
Non-repudiatable retention and validation for 25 years or more. Connecticut happens to be 25 years storage of medical records. I think we heard yesterday somewhere else it was much more than that. How are you going to prove these identities, et cetera, 25 years later? So we've got to make sure we have migration paths for all these components, the digital signatures, et cetera.
As we go forward in time, how do we take those old five inch floppy disks in essence, and have data, and make sure that we can still get access to and decipher those things as we go forward in time? It's a key requirement here.
Multiple signatures on any document I think we talked about yesterday.
And we have to transcend these industry boundaries. Yes, we are talking about health care, but the hospital sends the bill off to an intermediary, say an envoy, off to an insurance company, which then sends stuff off to the bank for the payment, and coming back and forth. So we have multiple industries, providers, et cetera.
So what we have done in health care then is we have tried to come up with a solution. First of all, we started out with very specific health care policy. I think this was key. Yesterday we heard the DEA talking about they were going to be coming out with very specific policies to meet their criteria.
Likewise, we are talking about policies here. There is a policy for an employee. There is a policy in our state for licensed practitioners. There is a policy separate for patients for example. Each have different levels of functionality that we want to recognize.
We have rolled out a certificate of authority. We have used Baltimore Certificate Authority. We have then tailored our own registration authority to be web-based at all the health care information that we were looking for. We have rolled out an online certificate directory, so that we can find the public keys, so we can encrypt stuff to people. It's a key resource needed in health care. How are we going to do that across states, et cetera?
Therefore, we put out digital certificates on smart cards, allowing the sending and receiving parties to take actions between each other. We have not yet rolled out the value-added authority. That would be for the key recovery kinds of components, or other value-added services, the time stamping, et cetera -- excuse me, key recovery.
And all of that eventually leads to the fact that it's still the institution in many cases, who owns the data, who has to put in place their own role-based access components. They still control the data. All we have given is an identity. Given that identity, will they allow someone in or not in to their database, based on the various roles?
So that's a model of the system that we have rolled out. We have not yet had the audit process. We think that NCVHS ought to have a key role in the audit process. One of the recommendations I have at the end is that not only should you be looking at health care-specific policies, I think you should be looking at a role where perhaps you would be making sure that the CAs and the RAs meet your level of criteria, to be able to say, yes, they cross-certifiable.
So I mention these policies. I think it's very important that we have health care-specific policies, and tailored to the different kinds of relationships here, very particularly the employee policy, not just a generic identity. You really are a relationship to your employer. You are only allowed to do certain things with regard to that relationship.
Also as we mentioned yesterday, some things are not individuals, they are devices. So the bottom two, the fact that there are organizational level policies to say that okay, the organizational servers, the organizational devices, et cetera that are doing encryption et cetera, need to have their identities also.
What we have rolled out, therefore, is a chain of trust. And I think there was very little talk yesterday about trust. How do we get from Jack to Jill in this scenario? One is an employee of an insurance company, and one is an employee let's say of a hospital.
To get there, we can first establish a layer of trust within the hospital if they are an employee of the hospital. We can then have groupings of relationships. In this case, a hospital association has a known relationship let's say with the hospital; the Connecticut Hospital Association with the Connecticut Hospital. They have that known relationship and trust. They can help find and create that community of trust.
Then finally, we need a CA to be able to cross those communities, and say I can get the trust of the hospital association, the medical association, the insurance company, whatever, in bind across them such that we can get from Jack to Jill in a chain of trust that is there.
Add to that layer now the cross-certification authority component that Rich talked about of adding to this chain now the fact you can Bridge the trust between the CHIME Trust CA and another CA, and do the same kind of chain of trust. That's what we are talking about trying to establish.
A key component Rich alluded to is establishing this cross-certification at the policy level. Now remember I talked about employee policies, for example. So it may be very feasible, but if we have a health care employee policy in Connecticut, and the federal government has an employee policy, and we follow the same grades of criteria of let's say high level trust on a smart card or whatever, that they can be cross-certified policy to policy, yellow policy to yellow policy.
On the other hand, if we don't have common policies, we get into the problem. Let's say we have a high level policy at CHIME Trust, but Vendor A has only really low grade policies, and they don't have a policy for a licensed practitioner, let's say. There is no way to cross-certify. So we need to be working towards policies that are common.
I think that's an area where NCVHS can take a major role, trying to help lead us down the path of here are maybe some minimal quality criteria for policies to say that we can get some level of communication going between each of them.
Another issue, yesterday we talked about various business pieces for digital signature. And on the chart here I show you an example of eight different entities, hospitals, pharmacies, et cetera, all connected with a single line between each of them. The one to many kinds of connectivity that you might think about having.
You get this huge mess of things now. And what I'm talking here now are not necessarily wire connections, but what does HIPAA talk about? It talks about establishing trading partner agreements. Do I need a trading partner agreement with every one of those people? And as part of that trading partner agreement, how they are going down into the details of their security policies, et cetera, in terms of establishing layers of trust between these institutions.
In my mind the business case is the following side, therefore, that puts CA in the middle, where you have the trading agreement between let's say the insurance company CA, and a separate individual line between the hospital and the CA, where they have agreed on the common policies and procedures. We are going to have an employee policy. We are going to do face-to-face recognition. We are going to do X, Y, and Z.
And we have minimized a lot of the burden of trying to establish all these trading partner agreements, for example. So I believe there is a business case for the digital signatures.
It also alludes to the federal framework, some of these requirements I think we need to be talking about in these policies. For example, back up of signature keys. We have been hearing today about digital signatures. Well, we talked about having an encryption pair of keys, and a signature pair of keys.
If you really want that high level of trust, you must not back up that signing key, because you are opening up that non-repudiation issue. So we want that level of criteria. These rudimentaries, by the way, are the ones that Rich talked about earlier -- rudimentary, basic, medium, high are the levels of trust that we are talking about.
Another one is the proof of identity. We have one entity that says hey, I'm just going to download certificates from the Web. I'm just going to go off to some database of whatever. But if you are in the database, you are fine. You'll get an identity, without face-to-face. That's one level of trust.
On the other hand, for some of the things we are talking about, we heard yesterday from the DEA, they are saying that level of trust doesn't work for DEA. They want the high level of trust, where there can be some level of proof that you have been there in person with the registration component.
You have probably shown two different IDs, government IDs, drivers licenses, et cetera, and really had some face-to-face proof of identity. That's the level of trust that perhaps we need for certain levels of application. So we need to be able to have these kinds of criteria in our policies.
These are the types of things that we're talking about in CHIME Trust as the types of identities that you need to be showing, your driver's license, your employee ID number, your DEA number, your doctor's license, et cetera, as proof that you can get those types of certificates.
A key requirement here is how long does the CA maintain their record? And that ties in my mind very closely now the requirement for retention of health care records. If your health care records are required to be retained for 25 years, but you have no requirement that the CA kind of live for any great length of time, or maybe only for 7.5 years, what are we going to do relative to this need to store data and information, and decipher those signatures 20 years from now? So we need that higher level of requirement.
In-dentity(?) protection of their identity. Some identities are being stored on the Web. They are floating all around in multiple components. I think Kaiser discovered for example, one of the drawbacks on one of those is that we talk about multiple factor authentication as higher layers of trust. Something you know, something you have, something want kind of thing.
Well, if you've got a roving kind of certificate that all you need to have is a PIN number, you are really back to single factor authentication. It's not as high a level of trust. The fact it's in something like a smart card you take with you adds the higher layer of trust. We want the higher layers of trust if we are going to be doing things like signing prescriptions.
In our case, we are putting them out on smart cards. No, I'm not Dr. John Doe, but that's where you have to go off and check my certificate to see if I'm really real or not.
Another component requirement here, what happens if the private key is compromised? Well, in health care we have some major potential there. We hear from the DEA they don't want Joe Hacker in there getting extra drugs, et cetera. They consider that a really high level of compromise and problem. So we need to have that requirement.
Let's talk a little bit about the authority. Within a hospital, are you within medical records. Are you within patient accounts, et cetera? So if you are dealing with an insurance company on the other end of the line, you need to somehow be able to represent that authority. NCVHS can help here with taking the ASTM kind of standard role, et cetera, and really trying to push that concept that we have some common roles and understandings and definitions of what we can accept here of various roles, so that when one entity says I am one component, the other entity can believe it.
So what we have done here is we have rolled out a series of applications in Connecticut. You might say, well, these are not necessarily applications. Well, in some sense they are. We made sure that we can work with e-mail, the number one application our hospitals want.
We made sure we can work with Web-based applications, those other products that we can put in the front end to make sure on the other end of the Web you are there, and if you try to sign a document from a far, that they can attest to it. Virtual private networks, EDI components, and the log on components, et cetera. We have tried those. We have proven those. We have tested those.
I'm going to branch off for a moment here on you, and go off to try to give you a real, live example here. If you look at e-mail as the key killer application for health care, is it live? Yes, it is. And if I go into my own personal folder here, you can see that if I try to bring up this e-mail I sent to myself, it doesn't allow me in, because it is encrypted to me. So I need to insert my identity into my reader, and I can then click on okay. It looks for my identity, validates who I am. If I put in my PIN number correctly, it allows me into that test message.
Now you will notice that Microsoft comes up here with a series of tests. This is another example of what we want to do for health care, is expand on this kind of testing. What are the requirements we need to be testing for?
Now you notice that it said my signature is invalid. This is part of the problem we do have with the off-the-shelf software. When I'm online, it says my signature is valid. Offline, for some reason, it doesn't like my e-mail address offline, as an example.
You will notice up in the top here it gives you kind of a chain. It says I work for the Connecticut Hospital Association. So we have mechanisms. I'm just trying to show you that it's there in a digital certificate, what we are looking for. It's really the tools that we have to embellish to make it work properly. So we have the fact that my employer, if we are looking for an employee, do I really work for Yale New Haven Hospital or whatever? No, I happen to work for the Connecticut Hospital Association.
If you also click on view the certificate, you will see that there is a lot more detail actually available. If I were online, I can click on the issuer statement, and it would hyperlink to my actual policy. So you could actually read the full policy of what's backing up this digital certificate. It's available. It's there. So the technology is really here.
You also see if you go to the details component here, there are other things that are right there -- valid from, for example. June 22, 2000 was when it was issues, valid to June 22, 2001. That's the validity period.
DR. COHN: John, I'm sorry, I don't mean to break in, but we obviously don't have a copy of your overheads or testimony. I'm hoping that --
MR. LYNCH: Yes, I was working on it even as of last night after dinner.
DR. COHN: I hope you're going to be completing here soon.
MR. LYNCH: Okay, I'll try to wrap up here.
Other key components here. You can see you've got the certificate revocation path. You can click on key usage for digital signature. This is one that I can use for signing for example, therefore, I should not be backing it up. The technology is there. What is not there is the other components. Some of the actual front end stuff that the Microsoft hasn't yet embellished. Rich talked about some that they are adding very soon.
What I was going to do was show you a prescription, and I think I've run out of time. A prescription to show you that I really could sign it, decipher it, et cetera online; a key component there. If you want to see that after, I would be delighted to show you live, that you really can do all that stuff.
And I'll try to sum it up here. I'll go back to my Power Point. Actual examples of what we are doing in health care. We have integrated with Lanier. They have a patient transcription system. Again, from a far, they are trying to have doctors do their dictation notes, et cetera, sign them. With Blue Cross it's really a Web eligibility access component. There is really no signing there. The first one there is digital signature. The second one there is not.
Web retrieval of lab results, et cetera. Mostly retrieval, not digital signature. Physical access, hospital doors, parking lots, et cetera. Again, that's not necessarily digital signature, that is more the authentication component. There are others, however, working on orders, including prescriptions, where you need to digitally sign the document. Again, offline I can show you that one, just through an e-mail.
Observations and findings, another business case. Anytime you are making observations, you are looking at an x-ray or something, you could be looking at that from home, trying to write the results, sign it, and send it back; those types of results.
You also have another one in Connecticut called the W10. Our Medicaid agency has this referral form that requires three different signatures on it. So to automate that, we need to have three different signatures, one from the doctor, one from et cetera. So those are all examples of what is going on.
I'll try to finalize now what are some of the remaining issues. We cannot look at this digital signature in isolation. It's really a combination of the signature encryption, authentication, et cetera. We've got a lot of Microsoft examples of gotchas where if you jump on someone else's hardware, it looks like the e-mail is coming from you. But maybe it is not. If you are forwarding an e-mail and you sign the e-mail for example, and you try to forward it, the signature gets dropped.
You can accept free loaded trust. So for example if Verisign has their certificates preloaded into the browser, it looks like they are trusted automatically, and yet you may not want to be able to trust that level of policy. We need to be able to turn those kinds of things off. Something like an e-mail, there is no way to do multiple signatures kind of thing. So there are other things where the applications can come along and improve. The basic core is there in the digital certificate.
Recommendations for you, to finalize here. One, a recommendation that you work on some standard policies. We talked about health care policies, employee policies, et cetera. Work with the DEA, et cetera. Try to come up with a standard policy for the DEA physician and the non-DEA physician for example. And enable us across CAs to deal with each other with that.
Bridge at the policy level. The federal kind of Bridge, if we had these kind of policies in place, maybe NCVHS is that entity that Rich talked about. Somebody has to become that agency that adjudicates the trust between those different components. If you have got standard policies, then perhaps you can adjudicate, at least for the Medicare component. Yes, these are equivalent, and you should be able to talk one to the other.
A standard credentials authority. Taking on those ASTM roles, et cetera. That we need to have certain standard definitions so that we say it's medical records in one, and medical records in the other. Or it's accounting in one, et cetera. A component here in terms of audits. I believe that perhaps NCVHS, if it takes on this role of policies for example, perhaps could say yes, these are valid CAs. They meet our minimum level of requirements, et cetera for policies, for procedures that they are following for Medicare-type cases.
Education of payers, providers are a major role for you we mentioned yesterday.
Across state standards. If every state comes up with different components, we need to be able to adjudicate across those. Perhaps we can superimpose on that some health care stuff that says this will supersede state stuff.
Lead by example. If HHS uses PKI, requires it for Medicare data, fine. You are not necessarily mandating it for the HMOs and other people who aren't Medicare, but at least you can lead the way, and many people would jump on the bandwagon if you do it.
Allow a CA to be an intermediary in your trying partner agreements. You talked about HIPAA and all these trading partner agreements. Perhaps we can alleviate and make that kind of business case.
Allow a CA to be a provider/identifier/issuer. I think alluded to yesterday was the fact that if the DEA comes out with stuff for doctors, and you have your NPI for doctors, and the AMA has their thing for doctors, and CHIME Trust has their thing for doctors, we've got to somehow simplify that process. And if you allow the CAs to be issuers of NPIs, perhaps we can alleviate that one step.
Create test beds. You go back to the DRG days. What worked when the new technology came along? Well, HHS sponsored test beds like New Jersey in that case, to say, okay let's prove it works before we out it. Well, I haven't seen any of that kind of stuff necessary coming here yet.
And work the vendors like Microsoft, and say hey, we've got these health care requirements for multiple signatures, et cetera. We know your off-the-shelf products, your e-mail, et cetera, doesn't allow for that yet. Get it there. Put your pressure on them.
In summary, that's my name. That's my home address, et cetera. I will not be with CHIME Trust in another week and a half. So if you need to contact me, you can contact me at this address and phone number.
DR. COHN: Thank you very much. Shelly Neuman.
DR. NEUMAN: Sherry Neuman.
DR. COHN: I'm sorry. I can't see this morning. My apologies.
Agenda Item: Report on Existing Projects - Sherry Neuman, Iscribe
DR. NEUMAN: I'll tell you a bit first about the company Iscribe, and why these hearings and the result of the hearings are so important. Iscribe is a private company that was founded in January 1999. The company's mission is to provide acceptable technology to physicians that will reduce medication errors, improve patient care, and help eliminate the administrative hassles with the current paper-based prescription process.
We do this in several ways. First, we know that we need to fit technology to the doctor's work flow. It has been said that physicians and other health care providers are technophobic, but we have found that that is not true. What doctors do not want, and will not accept is being forced to change the pattern of their daily practice.
So we have developed an application for a PDA, a personal digital assistant, either a Windows CE-based product, Compaq, Casio, that type of pocket PC, or a palm-based product -- the Hand Spring Visor, TRG Pro, or Palm -- that allows the doctor to select a patient, select a drug, and print, fax, or electronically transmit a prescription to a patient's pharmacy of choice.
More important though than the speed or the ease of writing the prescription is the fact that the selected drug has been prechecked for formulary compliance, and any potential problems that may arise due to drug interactions, or other therapeutic anomalies that may cause the patient harm.
We currently have about 750 physicians across the country using the Windows CE-based product, with about 1,500-2,000 waiting for installation. Another large group of doctors have downloaded the program to their own personal PDAs, the Palm-based products, and are writing prescriptions today.
Another requirement for technology among health care providers is mobility. Doctors are not stationary. They more from exam room to exam room, from clinic to hospital, and back again. And they are not in the office from 9 to 5. So the PDA, or this mobile technology offers the venue that physicians need in order to be able to interact with technology and accept it.
The need for that mobility, however, has presented the challenges that we are talking about today, particularly privacy and confidentiality of patient health care information. And the security of transmission of that information. At Iscribe we use both electronic and digital signatures in two ways. First, the digital signatures are used in our network operations communication center, using SSL-based key mechanisms that are RSA 2042 bits or elliptical curve for the public key cryptography.
In addition, our virtual private network communications use IKE to pass key pairs. And I'll just have to read this, because I'm not a technologist. But it's TES.DES-X 56 bit RCA. And that's all I know, because I read it about the product specifications. And that's for the secret key cryptography for data encryption.
These digital signatures enable us to insure the transactions between physician and pharmacies are secure from the PDA to our network operations center using Certicom, and to insure that transactions are secure between trading partners. And that would be such as retail pharmacies and processors or pharmacy benefit managers.
The results or benefits of using this kind of technology and these digital signatures are the ease with which we could set them up, and the maintenance with which IKE offers due to industry-wide standards for this network layer. We do not support open key exchange with trading partners at any application level.
Conversely, the major problem that we have encountered is the lack of a global approach. Each of the solutions takes a local view, and the interoperability or the cross-functionality is missing. Also, there is limited experience in this field, and each company is moving forward, developing its own almost proprietary way to deal with transactions. And because it is proprietary, there are these sort of trade secrets. That the information, even successful information is not be shared among the companies.
I believe though that all of the successful implementations will add to the knowledge that is required to establish standards. Hearings such as the ones were at yesterday and today, where ideas are shared, and open communication of best practices are aired will lead to the creation of policies and structure that all parties can follow.
The standards have to be dynamic, however, and account for improvements in technology. And we heard yesterday not to dictate a particular technology or a particular method of implementing technology, because as gain more knowledge and find better ways to do things, we want these standards to accommodate that.
Our plans to enable electronic signatures and digital signatures nationally include meeting with state legislative bodies. I will be meeting with about 45 state legislators from 20 states next week at a legislative conference, where these folks are asking for the take aways. Help us write the laws that will improve technology utilization within the health care field.
So we are doing a lot from the high level down, as well as grassroots up. Obviously, in order to conduct business, we have to be able to provide secure transactions. But my belief is that getting laws at the state level to allow the electronic transactions to happen with secure digital signatures and electronic signatures is also a very important part.
E-SIGN and UCITA of course have helped with that, because they have the laid the groundwork. Now it's up to trading partners and business entities in health care to apply the tenets of E-SIGN to our specific industry. That means passing laws at the state level that allow and encourage the use of technology to improve care and reduce costs.
The states often look to the federal government for guidance and direction. The final rule that will come out under HIPAA for electronic signatures will certainly allow the states to fall back on or use that as their authority to write the laws in their own individual states.
Thank you.
DR. COHN: Sherry, thank you very much. I really want to thank the panel. It's been a very fascinating set of discussions. I also want to encourage those of you haven't submitted written testimony, to make sure to submit it to Jackie obviously, because this is very useful as we analyze the information later one.
I want to just start with a question for Richard, and I'm sure others have questions also. Actually, there are a couple of questions for you. I apologize, I haven't met you previously. I was curious. First of all, I do understand that you are representing the --
MR. GUIDA: The Federal PKI Steering Committee under the Federal Trust and Information Officers Council.
DR. COHN: Exactly. I was just curious whether individually you are with the Department of Commerce?
MR. GUIDA: Treasury.
DR. COHN: The reason I'm asking that is because at least part of this legislation was supposed to be Commerce and HHS that was supposed to jointly decide this. So I wasn't clear whether you were representing Commerce in these discussion.
MR. GUIDA: No.
DR. COHN: Okay, thank you for that clarification.
Now one specific question. My understanding is that GAO has commented on the Bridge approach. I unfortunately have not read that document, but can you comment on both the substance and the interpretation or whatever was said in relationship?
MR. GUIDA: Yes, I can on a couple of levels. GAO, I have had a close relationship with them in the sense that we have had many, many discussions over the last six months. The testimony that I believe you are referring to dates back to May. And in that setting, they were in the early stages of engaging me in understanding what our effort was all about. That was in large part because of the fact that we had been able to successfully demonstrate the Bridge is no longer just an etherial or conceptual model. It was actually something we had demonstrated in prototype form, as I described.
So at the time, the testimony basically said this is an effort aimed at trying to effect interoperability across agencies. It didn't take a position as I recall at least, one way or the other, that this either was the way to do it, or not the way to do it. It just simply reported that this is an effort underway.
Since that time, over the summertime, I have had, as I say, lengthy discussions with GAO, discussing not only the Bridge model, but more importantly, the policy model. The issue of the policy authority that I mentioned. The fact that we are working very hard to get a policy authority in place, and have succeeded in getting one in place. We have a charter for it. The Seattle Council fully endorses it. It's part of the CIO council now, a separate body.
It is chaired by one of my dear colleagues, Michelle Moldinouer(?), who is also from the Treasury Department. So the bottom line is we have had over the summer, had extensive discussions on this. And I understand GAO is going to be coming out with a report in the next month or so that will discuss the results of all of those activities.
Now exactly what it says, I don't know. And I will be eager to read it, obviously, once it does materialize. But I believe from the nature of my discussions with them that they appreciate the value of this approach, and can see the merit in the approach. But I certainly can't speak for them. I would never be so presumptuous as to do that. So you need to obviously -- like all of us, we need to wait and see what they actually say about it.
May I add one thing, if I could, sir? One of the points that John made was particularly important. I regret not having made it myself, but I'm now going to shamelessly steal the point. And that is the issue of what this committee could do in the way of helping to bring some sort of coherence to what is inherently an incoherent situation across government as a whole. And it's not just unique to the health care area, it is everywhere.
The issue is this. In the policy area, certificate policies in particular, as I alluded to, every agency has its own certificate policy for its PKI. We have right now over three dozen agencies doing PKI work, tests or production uses. We have five production uses of PKI. And when I say production use, I mean an agency relying upon digital signatures and/or the encryption capability of PKI to support that agency's mission role, mission accomplishments.
These agencies include the Federal Deposit Insurance Corporation, which has all 7,000 of their employees PKI-enabled, and they are enabling their member institutions. It includes the Federal Aviation Administration for digitally signing aircraft safety material. It includes the US Patent and Trademark Office for getting patent claims.
The point is they all have their own certificate policies. DOD likewise is an enormous user of PKI. They all have their own certificate policies. What we have been trying to do in developing the Bridge certificate policy is to develop a policy that can be emulated where agencies wish to do so, or at least elements can be adopted into the agency certificate policies to facilitate policy mapping at a later time.
So if I'm an agency and I'm more interested in one level of assurance certificate, let's say my certificate is called the Z certificate. Let's say I only need one level of assurance. If I know that the Bridge certificate policy offers four levels, and I know I sort of want to map to the medium level of Bridge, will I really see what the medium level of assurance at the Bridge contains.
Well, let's see. It contains an in person identity proofing model. It allows software/hardware encryption. It requires 1024 bit RSA. In essence, you can take a look at all those requirements in the certificate policy at the Bridge level, and you can say if I fashion my certificate policy in this way, then I'll be able to map extremely well at the medium level, or whatever level I wish to at the bridge.
So what we are encouraging agencies to do is to look deeply into the Bridge certificate policy, not as something that they are slavishly going to have to adhere to, but rather something which if they happen to conform to one of the levels well, it will make it easier to policy map later on.
And in fact in the production of the Bridge certificate policy, I would tell you it has been like one of Cecil B. DeMille's work. It's been taking a long time to produce. And part of that is because we have a lot of agencies working on it. It has taken over a year. I have gone through about 15 editions of the darn thing, and frankly, I'm proud of that in one sense. Not proud, because we in government sometimes don't work fast enough. I'm proud in the sense that it represents a consensus of all of the members of the steering committee, which represent over 24 agencies, over 50 members.
We just completely our work on it last week. We have sent it forward to the policy authority. The policy authority will now give it their review. When they are done, it will go to the entire CIO council for its review. So we are trying to do this in a methodical fashion, but in the final analysis we are encouraging agencies to emulate the provisions to the extent they feel comfortable. It will later make it easier to interoperate with everybody else.
DR. COHN: Thank you. Questions or comments?
MR. GELLMAN: Rich, a question. I'm sorry I missed the beginning of your presentation. I am particularly taken by the records management, the archival records management issue that you raised. This is an issue that I have sort of followed for a long time.
About ten years ago, maybe a little longer, I did a report for the House on the issue of archival preservation of electronic records. I know there has been some work done in the interim years. I'm not really sure we've gotten very far in figuring out what to do and how to do it.
In order to preserve the utility of an electronic document, depending on what you are doing, you may need a medium that you can read on a long-term basis. You may need software that can read it and reproduce it. You may need hardware. In order to run the software you may need a particular operating system in order to do it. It's a big enterprise, and it's not something easily solved.
Now in this context, the PKI context, it seems to me that now you raise a problem that it's not just a matter of preserving equipment or hardware or software to do it. It's a whole structure. It's a whole structure of nested institutions that all work together in order to produce the results that you want. And if those institutions don't exist or have evolved or whatever, all the sudden we have taken a really difficult electronic records management problem and we've magnified.
You can't solve it on your own. You have to have everybody else in place in some fashion in order to do that. So you sort of take the challenge, and now you magnify it. It's now a whole other order of magnitude of difficulty. How do we deal with this?
MR. GUIDA: Well, actually I would argue that it is not quite as difficult as you have portrayed it. But your point is correct that it is an issue that has to be dealt with. Let me address each point that you made. You have posed an extremely important question, and an intriguing one, and I have to unravel this, if you will give me a chance.
First of all, you are correct that electronic records management today, who still has Word Star? Who still has Visical(?)? So if I've got files in those formats, I'm going to have trouble dealing with them. Sometimes I even have trouble dealing with Word 6.0. So the point is, you are quite correct that I've got an issue that I have to worry about there.
Now what I encourage agencies to do when they think about how you are going to want to preserve records for the long-term, and I'm not just talking digitally signed record, any record. I encourage them to think about it in terms of what formats have the longest legs, are at least likely -- to the extent one can ever predict these things --are least likely to change.
There are some formats which I do believe have some robustness in that regard. One of those is PDF. Another is the upcoming XML-based formats where you do have at least some hope of preserving information in a fashion which is not going to be altered. The fundamental underlying format of the information will not be altered very much over time, if at all. So electronic records management, from that standpoint, is very important.
Now if I'm looking at media conversion, going from the 5 1/4 inch floppies to the CD ROM, currently as long as I make that conversion with 100 percent fidelity, then I don't have an issue of destroying a digital signature. The issue of destroying the digital signature only comes when I reformat a document, and I add control characters or the basic content of the document changes in some fashion. Either the words change, or more importantly, the formatting changes.
In that kind of a setting there are a couple of approaches that agencies are contemplating using. One approach I call the NSA approach. Basically, they keep copies of every single format, every single word processing program. They have a library copy of virtually everything. The reason they have to do that is they are obviously in a business where they may have to read formats that are many, many years old. And they can't wait to try to do it.
So one approach is the brute force. Save a copy of all of your software that you have ever used since day one. That's a pain. I'm not suggesting that universally.
MR. GELLMAN: And anyone who doesn't have an unlimited budget can't do it.
MR. GUIDA: NSA doesn't have an unlimited budget either now. Now the second approach is what we call the digital notary approach. The digital notary approach basically is this. When you have documents saved with signatures, and at some point you decide you need to execute a reformat, you need to change basically these documents, or convert them into some other form in order for long-term storage or whatever.
The digital notary approach basically has an individual authorized within the agency to take a document, validate the signature on the document, and then convert the format and sign over the changed format, basically attesting to the fact that this digital notary has tested the signature, has met all the following steps, has lifted CRLs, et cetera. Did a time stamp check, whatever.
Did all the due diligence things, and then did the conversion, and now the digital notary signs the document in the new format. For many applications, agencies feel this is an acceptable approach. I'm not suggesting that it is -- in the context of criminal behavior, I cannot contend that this is sufficient. I'm not an attorney, so I would never contend anything is sufficient.
But my point is this is an approach which some agencies view as very workable. Sort of a large scale conversion with a digital notary.
MR. GELLMAN: I would add a point there. In the federal context, where long-term preservation of records is basically a very small fraction, 2 percent of records are preserved long-term, other records, 5 years, 10 years, and then they disappear. It's not as hard a problem if your time frame is relatively short.
In the context of health care, where records are kept routinely for very long periods of time, and possibly forever in some cases, this progression of the notion of converting from one format to another ultimate as you move down the pike becomes an enormous expense difficulty, and something that will simply never happen. So that may work in some contexts. I'm not sure that's scalable more broadly, and that's okay. That's not to ask do you accept it for yourself.
MR. GUIDA: I would say in the case of the Navy, for example, where I know many agencies are contemplating this, they have to worry about preserving records on their construction of nuclear powered aircraft carriers for 75 years, because they will be sailing out a long time. So I respect your point, but I do think there are some elements in government that have to do that.
Now I just want to answer a final point in your good question. I don't believe that the preservation of information required to validate a signature way after its been made is quite as bad as it seems, because if we for example I get a digitally signed document from a private company. I'm a federal agency. I save the document. It is digitally signed using a certificate issued by that company to its employee let's say.
And as you posit, 15 years later I want to validate that signature. Well, there are a couple of things about that. If I want to save the information required to be able to say with confidence that signature was legitimately made at the time that I received it, the information required that I have to save isn't that much.
I have to save the certificate that you presented at the time you gave me the message. I have to preserve the certificate revocation list, or the request I made to an online certificate status protocol responder that says your certificate was valid at that time, and had not been revoked. I have to save a trusted time stamp, so I know exactly when the event occurred, which is something I would need regardless of whether it's a digital signature or not. And that's about it. There isn't much more.
MR. GELLMAN: Do you have any encryption codes anywhere so you can unencrypt all this stuff?
MR. GUIDA: That's mine. I control that myself. See you talked about I get a transaction from somebody else. And I have to worry about saving information that is under the control or possession of that other entity. The encryption information, the person when he sends it to me, encrypted it using my public key. If I don't have control over my own credentials, then I'm truly in dire straits.
MR. GELLMAN: Those are other elements that need to be preserved.
MR. GUIDA: Oh, yes, but that's within my own control is what's I'm saying.
MR. GELLMAN: That doesn't make it any easier. I don't care whose control it's in, preserving stuff for 50 years is hard to do.
MR. GUIDA: My point is if it's under my control -- I thought your question, I'm sorry if I misunderstood it was if I'm trying to control things or have things under somebody else's control, that's inherently more difficult than trying to control my own domain. In my own context, you're right, I have to control that information. But what I would observe is that there will be a need to preserve network logs and network information and audit records and all of this electronically for a long time, not just because of PKI.
Any kind of electronic signature that I choose to employ, PINs, passwords, you name it, I've got a need to save a lot of information for long periods of time. We've got to solve that problem, and frankly in my view PKI solves it better, because institutionally the elements you need to be able to prove a signature later are pretty well defined. The certificates, the CRLs, maybe a certificate trust path if you need it, and that's it. And in terms of quantity of data, that is not that much.
MR. GELLMAN: Let me just make one point. I have another question, but I'll wait on the other one if you want. This issue of long-term preservation of records in electronic format is not something I have heard come up before. And I'm not talking necessarily limited in the PKI context for electronic records.
I don't know if there has been any discussion of that. It might be an interesting issue at some point for the committee to raise, just to add a whole other layer of complexity to what's already a pretty complex issue.
DR. COHN: Sure. I'm not sure that I'm more worried about previous versions of Microsoft Word and Visical for this other issue. But we can discuss that later on.
I would like to open it up to allow some other people to ask some questions that they have. Questions, comments? Kepa, I think you have something.
DR. ZUBELDIA: Thank you. I want to thank all the testifiers, because you provided different views from what we had yesterday. And it's always refreshing to see different things.
Before I ask the question, one of the things that I noticed that was interesting was that in John's demonstration, he showed the encryption of an e-mail message using his private key and that smart card. Where the private key had been flagged only for signatures, not for encryption. And this was an encrypted message that was being decrypted with that key.
You also showed how the verification of the signature failed, because there is something that works differently when you are online than when you are offline. It showed that the technology is not here yet. It's a very promising technology, but until the vendors can fix this and make it reliable, 24 by 7 by 365, and as reliable as fingerprints and other biometrics, I think we have the same problem.
If we cannot trust a signature because we may be offline, it's a problem. And I think it's a problem that can be fixed. The technology will get there. And if it gets adopted by lots of people, they will have to make it happen.
MR. LYNCH: I would like to respond. The technology is there in the sense that the digital certificate contains the proper information. You can visually do the checking, and say whether you want to trust or not trust that particular document.
The problem I think you are really alluding to is the fact that the off-the-shelf implementations today have a way to go. And that's where I come back to my recommendation that you push the Microsofts et cetera to get rid of some of these components by issuing health care requirements that we must have multiple signatures, we must have a sign in key separate from, et cetera. If those requirements are out there, I believe that Microsoft will suddenly implement a sign in key separate from an encryption key, et cetera.
So it's not that the underlying technology -- the PKI infrastructure is there. The certificate has the right information. We just don't have the automated way to trust. Who wants to go through manually checking each one of those little boxes. I deliberately showed you those boxes to show you it is there.
What we really want is the automated way so the pharmacist or whatever can just click on it and say, yes, it passed all of the criteria that we set up for a prescription. Yes, it passed all of the criteria that we set up for I don't know, a medical record this or that kind of thing. To have those things automated by software, rather than having to visually check them. But the underlying is there.
MR. GUIDA: Let me add, sir, on that point, to respond to Kepa's point. What John demonstrated was an s-mime Version 2 Outlook Client. S-mime Version 3, which is what is coming out in the next version of Microsoft, which has been demonstrated to us already -- it's out in beta, and we are evaluating it now -- does everything that John just described.
It uses dual key pair. It does not slavishly adhere to your e-mail address has to be in the alternate subject main field, or else the thing fails to validate. It doesn't do a lot of the things that earlier versions have required.
So I believe that Kepa is correct that most of the clients deployed today, if you go to an office today, what do they have? Well, they have probably the S-mime Version 2 version of Outlook, the Outlook 97 or Outlook 98. If you have Outlook 2000, and particularly with the Outlook 2000 version that is going to come out shortly here with what is called Whistler, which is what we have in beta, we have evaluated, those issues are exactly addressed.
And this is not conjectural. They have been demonstrated to us. They do work. Dual key pair, the ability to basically process certificates offline. In essence, what it gets down to is what John said. Does the client software, whether it's an e-mail client, or any other client software, does it process the information in the certificate in accordance with the X509 standard, or doesn't it?
Well, some of these software versions don't, and others predated the current version of the X509 standard. So you once again have a case of the standard has improved, and now the improved product is going to come out behind that standard.
DR. ZUBELDIA: Could I ask the question that I had? Because that was just a comment. The comment I guess generated much debate, before I ask what I wanted to ask.
Yesterday we talked a lot about signatures. And today we have talked a lot about PKI. And granted PKI is a secured mechanism that can be used to encrypt, and also to sign. And I would like to center more on the signature side, than on the PKI side as a security mechanism now. Holt commented that we need to have interoperability among the certification authorities.
We need to have interoperability in the PKI components. We need to have interoperability in the signatures. And before we can have interoperability in the signatures themselves, we need to find signatures that work for health care, that meet the requirements that we have in health care. And those may or may not be PKI-based.
Sherry testified about the use of biometric and PKI. I would like to understand how that sort of combination, in your view, since you are all using PKI, how would that work for health care? Is that a positive combination? Can a biometric graphical signature for instance, assist in what we are trying to do?
Keep in mind that from what I understand, HIPAA has a requirement for electronic signatures of the transactions, not e-mail, but the HIPAA transactions. Now we have some administrative transactions, and potentially in the future we would have other transactions, including prescriptions. How are we going to have electronic signatures of those, and does biometrics help there, or is PKI the only way to do it?
MR. LYNCH: The first response on the biometric, we have tried a variety of different biometrics. We tried PIN-op(?) for example. My signature was never stable, and others were never stable. It wasn't reliable enough for 24 by 7 for health care.
We tried facial recognition. And we had one black woman administrator who they tried to test. We had a whole bunch of health care people. Prove it vendor. Well, I'm sorry, your head is tilted maybe the wrong way. Oh, it's the fluorescence light. They couldn't get her. Once she was enrolled, they couldn't verify her later on. It's not reliable enough.
We have had fingerprints. Well, we had a gentleman from Lockheed Martin testing with us who had no hands. He couldn't use his hooks really. They couldn't really test that. Fingerprints -- rubber gloves in health care. This doesn't work through rubber gloves. We are taking them on and off. Rubber gloves leave a powder residue, which sometimes screws up. One percent of the population that is Oriental many times, have real fine fingerprints that can't be detected.
And we don't have any standards on the biometrics. So if you go into Yale New Haven, and you use one biometric, and now you are trying to prove yourself to St. Raphael's(?) down the street, who has a different biometric system, and they don't compute, because they have different algorithms. There is no standard for between the two of them.
So we think biometrics aren't quite there yet. By the way, retina, the experts from Oak Ridge National Labs said they would never put their eye up against that laser. And by the way in health care if you are putting your eye up against this device, you could be spreading pink eye. So maybe now you're spreading disease at the same time.
So biometrics, we feel, are probably a generation away. We do believe that there will come a point in time when they are reliable enough for health care that you could use them to open your digital certificate. To have what you are, what you know, et cetera, kind of have a higher level of trust there.
The problem we anticipate for health care is the multiple types of devices you may have to have. If they are not 100 percent all kinds of patients, all inclusive, you need to have three or four devices at a machine where okay, maybe I'll take facial, because he has no hands or he's got rubber gloves, or maybe I'll take whatever.
So we think it's coming, but it's not quite there yet. And it will only be used to open up your digital certificate, because a biometric by itself isn't really bound to a document they way we've got all the technology to bind the digital certificate for that non-repudiation, that long-term proof that the document hasn't been tampered with, et cetera.
MR. GUIDA: I just want to say I strongly support John's points, and I want to go beyond them a bit. Our experience in dealing with a lot of the biometric vendors is that when we ask them questions along the lines of what are your false positive and false negative rates, we don't get good answers.
We ask them what algorithm are you using for the creating of the template that is used for registering your biometric identifier? What is your algorithm? How do we know that your algorithm has been tested adequately, and really has the kind of strength that we know resides within the RSA algorithm, or the DSA algorithm, the digital signature algorithm, or some of the PKI open standard algorithms? The answer is there is no answer.
Now I say this not to impugn biometric providers, because like John, I do think that biometrics can play and will play ultimately a very powerful role. But for right now the concerns that the solutions are proprietary. The algorithms are proprietary themselves. They are not interoperable. And we do not have good data on false negatives and false positives that really would allow us to say with any confidence how reliable are these ways to authenticate oneself.
And in the final analysis, what is a biometric identifier? It is a shared secret. It's like a PIN or a password; more sophisticated, but it's like a PIN or a password. You register on a template. Some other entity has that template if you want to do remote authentication. And if that template ever falls into the wrong hands, what do you get? An identity theft.
Whereas, with the PKI you are not sharing anything. You may have a PIN or a password or a biometric that you use to unlock your local token, but you're not sharing it remotely with somebody else, where some other entity has it under his or her possession.
So in the final analysis, I'm all for the technology biometrics used properly, just like I think PINs and passwords are wonderful used properly. And in my view, any shared secret used properly, is a shared secret between you and some inanimate object like my hardware token, my smart card. That is the proper use. Otherwise, shared secrets are oxymorons.
DR. NEUMAN: Just to also give some examples, we tried biometrics as well. The handwriting didn't work. It wouldn't let anybody else into the device. It wouldn't let each of us individually in either.
I would like to make a comment though about the fact of, and a need for the digital certificates. One of the presentations guarantees that nothing has happened to that document from the time it was signed, to the time that it is opened, or receiving entity. The rules are already in place for pharmacy for many states. They are called no intervening entity laws.
So when the physician sends the prescription to the pharmacy, no intervening entity should have access to that document. So we already have rules to write to, and that's why I think this is not an area that we are going to be able to skirt around. The digital certificates will be required if we are going to send any transactions.
And even regulatory agencies that are not necessarily at the highest level of state government, they are not writing the laws, but they have their own rules and regulations, and we will need to meet those.
DR. COHN: Other comments, quickly?
MR. ANDERSON: Yes, I would just like to say I hope that biometrics is a technology generation away, and not a human generation away. We have in the experience in the immunization pilot of trying to deploy digit certificates right off the bat with the browsers, the interfaces that we built to access the immunization registry.
The practical aspects of doing that, where there are multiple users on multiple work stations just stopped us dead in our tracks. The browser technology wasn't there. You would essentially have to boot up your machine every time a new person came up, or you would have to use some type of token or something else that contained the certificate. So it just stopped us, and we couldn't deploy certificates right away.
If we really think about what we are trying to do is enable health care, and the practical aspects are we have got to get technology out of the face of the clinicians. We've got to have a work station they can walk up to, and very easily identifies those individuals, opens it up, single sign on, they are there at all their applications, and they walk away from that work station, and it shuts down.
And I think the committee can help paint a vision of what health care should be in terms of assisting with holding people accountable for accessing data, and make it easy for that to happen in biometrics and PKI. Digital signatures are pieces of that puzzle, but they are not all together yet. We haven't painted that picture. And technology is going to evolve, and we just need to continue to hack away at that jungle. We can't stop.
The clock is ticking or soon to be ticking. And we don't have time to play with this for three or four years. The liability that the law is painting for violations of access are too much for people not to take seriously. But we don't have the technical solution.
DR. COHN: Thank you. Jeff, question?
MR. BLAIR: Please help me sort this out a little bit. Clearly, we need to facilitate interoperability. And in order to facilitate interoperability, we may have to drill down to sum degree in terms of the specificity of standards or policies that facilitate interoperability.
I was so encouraged to hear about the Bridge project within the government. It sounds like there is a great deal that has been achieved with that. Several of you mentioned that you were suggesting that the NCVHS recommend policies. And if I heard correctly, there were two areas. One was with respect to policies for certification for Bridges. The other one, if I recall correctly, was with respect to role and class-based access controls.
And the thing that I am looking for help on, and clarification for is how far do you think we need to go in defining -- let's take role and class-based decisions for access controls. Do we simply need to specify that each institution or entity has to look at that and make their own decisions? Or do we have to go further than that in order to facilitate interoperability?
Give me some feeling of how deep we have to go on that, and also on the policies that facilitate the Bridges and the sharing and the interoperability.
MR. LYNCH: I'll take a first cut at that. First of all, ASTM has a set of health care roles that it has come up with. I think that's one level of a standard definition, that if we were all using the same definitions, at least then at the other end of the wire, if we knew someone was being represented as that particular component, we would have some better sense other than that.
I think it would be going too far for you to say who could get into that particular database. That would be one step too far. But I think you do need to do some level of standards of definition, accepting those kinds of ASTM role, or whatever at one level.
A second level is something that isn't necessarily at the directory level, but may actually need to be in the policies themselves. And that I'll call employee level --
MR. BLAIR: By the way, just for my benefit, could you tell me who you are?
MR. LYNCH: I'm John Lynch. I'm sorry.
The policy level I think needs to have some level of component in there to distinguish that maybe you are a physician who is DEA certified, versus maybe you're a physician who is not DEA certified, et cetera. So there are various levels that I think need to be in the policy; others that are left into say a directory or a database that need to be exchanged and shared with people at the other end, to know whether or not you should be in or not.
I'm not telling you which should be in necessarily in the certificate, but that both are valid components that need to be addressed, and we need standard definitions in order to be interoperable.
MR. GUIDA: Mr. Blair, this is Rich Guida. I concur again with what John said. I would add the following to it. Normally when we think of interoperability, there are a couple of elements. I already mentioned or we already discussed the issue of a certificate policy, and the levels of assurance, and how you might fashion, if you are developing your own certificate policy, a policy that has elements that conform to somebody's, so that you will be able to map the two appropriately. And how the Bridge certificate policy, we hope, will serve as sort of a common template for that purpose.
But beyond that, along the lines of what John mentioned, there are other elements to make PKI work together. These are actually captured in the Bridge certificate policy. We list these.
A second element is a directory profile. In essence, if you want to have your directories work together with common schema, where the information on certificates and certificate revocation lists is populated properly, there is a thing called a directory profile. We are developing that now -- NIST I should say. NIST is developing that.
And by the way, the head of the computer security there, Bill Burr(?), is a chair of the technical working group under my steering committee. So we have very close ties to NIST, and very productive ties.
The third thing, certificate profile. A certificate profile is nothing more than a description of the contents of a certificate. It basically says in addition to the standard fields that exist in a certificate, like your name, your public key, your validity dates, et cetera, there are a certain number of extensions.
And we have adopted a federal certificate profile that provides for extensions which, if you develop a certificate that is to be interpreted by federal software. These are the extensions that we would expect to see, and how we would deal with them.
Now it's not to say that these are the only extensions. One of the nice things about X509, the standard, is it's extensible. So if you were to present us with a certificate that you wished for one of your employees, who happened to use other extensions beyond the ones that we prescribed, would we reject it? Not in the least. That would be a matter of you working with an agency to make sure that your fields are interpreted the way you want them to be interpreted, or your extensions are interpreted the way you want them to be interpreted.
But my point is we are telling the world at least, if you use these extensions, here is how we are going to interpret them. Let me give you an example of one of those extensions, because this is a very important. The example is main constraints. One of the things one always worries about in PKIs that cross-certify or try to interoperate is a thing called transitive trust.
The Department of Treasury cross-certified with the Bridge, the Bridge cross certifieds with DOD. So DOD wants to rely upon Treasury certificates, and they create this trust path through the Bridge of cross-certificates. What happens if in a moment of weakness, the Treasury Department cross-certifies with Cuba? Suddenly, I've got a chain of cross-certificates where the Department of Defense could suddenly be able to create a trust path all the way to a Cuban certification authority, and they would be very disconcerted in DOD if they had such a thing.
Well, the name constraints extension is exactly a field aimed at dealing with that consideration. When the certificate is issued by the Bridge to the Department of the Treasury, that certificate would contain in the name constraints field, a listing of those certificates under what part of the DIT, the directory information tree, Treasury is authorized to provide for the interoperable universe.
For example, you would say, C, who is US. O equals US government. OU equals Treasury. So what I'm creating now is a certificate trust path. If I've got a C equals Cuba over here somewhere, yes, I could clear the trust path, because all the CAs are cross-certified.
But when the client software at the DOD end starts to process that trust path, it notices that the certificate issued by the Bridge to the Treasury Department says any certificate that comes through this door has to be within C equals US. O equals US government. OU equals Treasury. Oh, this certificate is C equals Cuba. Forget it. It doesn't validate.
MR. BLAIR: That is an excellent example that I think could help us understand what is the threshold level where national standards might be required. Do you have that already in the hard copy testimony that you have given to us? Or if not, are you able to give us a listing of those areas where national policies will facilitate interoperability?
MR. GUIDA: I do have some of that in my testimony, but, sir, what I would propose to do is, if you look in the certificate policy -- I will be happy to provide a copy of that to you. Plus a separate report that we have put out in June. We described these elements that have to come together in order to make things work: the directory profile, the certificate profile, the certificate policy. These are the key elements. And as I said, they are all captured in the certificate policy itself actually. The certificate policy does capture all these things.
And I would be more than happy to produce even a custom document for your purposes. I don't even charge contract wages. So you tell me what you need. I'm happy to help you on this.
MR. GELLMAN: Back to you, Rich, on another matter. One of the concerns with all the PKI stuff we have, we talked about it a little bit yesterday, are the privacy consequences. The issuance of certificates creates a pile of information. And then transactions activity creates yet another database of activity. So actually that's the level. We are not just dealing with privacy, but we may also be dealing with information with corporate sensitivities. Who is talking to whom tells me something.
I'm wondering in the context of what you have done with the PKI pilot stuff, and what's going on in government, has any one of you dealt with compliance of the privacy act or the privacy act system of records that have been created for this? Are they around? I'm just wondering if people have thought through some of these issues, at least in that context?
MR. GUIDA: Absolutely. You are quite correct, all the records that are created as a consequence of the registration process for users are absolutely privacy act system records, and have to be protected in accordance with the privacy act.
DR. ZUBELDIA: Excuse me, let me point out what Bob Gellman is concerned about. The log from the OCSP responder --
MR. GUIDA: I'm getting there. Thank you. I was starting with the registration authority first. Just as Bob said, there are a lot of different databases. The biggest database by and large is the database of information on when you register a user. In large entities so many users, you have an enormous database of information on those users. That information is protected under the privacy act.
Information with respect to the use of certificates would be, depending upon how agencies design their applications, would either be protected under the privacy act, if it is retrievable obviously in accordance with some identifier associated with the transacting party. Or if it is not retrievable in that form, then it would not be.
What I can tell you is that all of the elements of the databases created by certification authorities when they issue certificates, registration authorities when they register users, OSCP responders, when they respond to certificate revocation status requests, all of those databases, if you look in our Bridge certificate policy, we basically reflect the fact that the agencies have to be aware of the fact that any data the preserve, archival data, maintenance data, whatever, has to be subjected to the tests of does it provide for the retrievability on the basis of an individually identifiable indicator of an individual?
So those factors are identified. I would go a step further and tell you certainly. Do I have 100 percent confidence that people full appreciate or understand all of this stuff yet? No way. And I say that not to be disparaging towards the agencies but this is something we have to remind them of frequently.
What I can say with confidence is we have thought about it. I can't tell you absolutely that I have audited the agencies who are using the technology, that they are actually doing all these things the way we would like.
One final point on that if I could. We do have a requirement in the federal Bridge certificate policy for audit. The audit requirement includes an audit not just of the way the PKI is operating, but also auditing functionality with respect to compliance, with statutes, regulations, et cetera. So it's more than just a compliance audit of do you have a monitoring log in place? Do you check the monitoring log? It's more of a management audit to make sure that all the elements that are going into the operation of this entity are being complied with.
MR. GELLMAN: Or at least for some agencies for some activities there are existing systems of records, notices published?
MR. GUIDA: To be honest with you, I can't tell you. I presume there are, but to be honest with you, I have not checked that individually. It would be an interesting test, but I'll go ask the FDIC if they have such a thing in place.
MR. GELLMAN: I was wondering whether they are out there. I would want to see the content of them, just to see how they handle some of the issues.
MR. GUIDA: We did this for ACES for the access certificates for electronic services. For the public issuance of certificates, there was a Federal Register Notice made covering that system of records, but I don't know about the agencies.
DR. COHN: Jeff, you had a question. And Kepa, do you have another one?
MR. BLAIR: My question is on the federal government's grid certificate policy. I would like to ask those that are kind of more representing the private sector, Holt and John and Sherry, as you have heard -- is it Richard's testimony, do I have name --
MR. GUIDA: Yes, sir, you do.
MR. BLAIR: As you heard him describe the federal Bridge certificate policy, did you feel comfortable that a lot of the things that they have developed are transferable to the private sector, or are there some aspects that you have run into in your experience that we also need to consider?
MR. ANDERSON: Jeff, this is Holt. Within the HealthKey consortium there are folks who understand the technology of this better than I certainly do. Of the alternatives that are there, this seems to meet a lot of the prerequisites that we were looking at. We are not sure if within the membrane, how it treats encryption at this point in its current state. And there may need to be some more engineering there to handle that piece of it.
Nevertheless, we are encouraged that -- and I have heard more today about the policies you have backing this up. That's been one of our concerns. How do we build a business model to make it work. We think the technology has a lot of promise, and we're anxious to try that out, having the business models built in as well.
And that's where in these pilots we could really use some help and encouragement and cheerleading from federal agencies. If we need to get some permission from some areas to participate, if you can provide assistance for that, it would be greatly appreciated. But we are encouraged. We had a very productive meeting, as I mentioned, about a week and a half ago.
Some resources are already being committed toward the project. We have had interest from various CAs, talking to the various states who see an opportunity to prove that this can work in health care. There are not many sort of public test beds that this can happen in.
We are also encouraged that the vendor who put the Bridge together is a 501(c)3, not a profit organization, and that perhaps this can be seen as a neutral facilitating entity to make it all happen. That there is not that commercial interest there.
So we are encouraged on a lot of fronts. We have just begun to start putting the project plan together. I'm sure that we'll get into some of the devilish details as we work through that, but Minnesota and North Carolina are committed to go on this path.
DR. NEUMAN: As I mentioned before, I'm not a technologist. But from an operational standpoint, what impressed me was that this was commercial off-the-shelf software that was tested. So it was not something that was engineered to make work, but was taking products that were made to work together. And I found that very impressive.
MR. LYNCH: We had some offline discussion with Rich before the meeting, which helped convince me even more when he was explaining some of the details. That they are down to the OID policy level, cross-mapping --
MR. BLAIR: I don't know what OID is.
MR. GUIDA: Object identifier; the way you express a certificate policy in a certificate.
MR. BLAIR: Thank you.
MR. LYNCH: So that they are cross-mapping at that level, which meant we are at the policy level, not at the CA level. That was very encouraging to me. And the fact that we could have multiple of these OIDs or policies in any one certificate, so that you could have a certificate that both said you were DEA let's say. Let's say you had a DEA policy OID, and a state licensed physician OID, both in the same certificate. We would be able to map and decipher those kinds of things. I was very encouraged by that.
In terms of what is missing, I think it comes back to what we recommended earlier. And that is it's the consensus around those policies. And I believe that's the role for NCVHS, to take that kind of lead role there to say hey, here are some minimal policies to get us cross-talking. And some minimum definitions, whatever, to get us to the point where we can use the Bridge, because the underlying components that would go into the Bridge are at some level of standardization.
MR. GUIDA: May I add just one quick there? That is the issue on encryption. It's a very important point. The Bridge itself, inside the membrane where we have these CAs that we have cross-certified internally to make them work, there is no actual encryption that occurs inside that membrane. The only thing that happens is you have a cross-certificate, so that if for example, you as an end user, you are down here under one domain, you want to get an encryption certificate, because you want to encrypt something to send it to somebody else in some other domain.
Well, you get that certificate out of a directory, but the all the Bridge does is allows you to determine whether you should be able to trust that certificate before you then actually go ahead and encrypt information using the public key in that certificate. So the Bridge itself actually doesn't do any encryption of its own volition. It doesn't heed the decryptions keys. It doesn't do any key recovery. It is strictly a conduit of trust.
That's the way I like to think of it, it's a conduit of trust. Moreover, it's not even a router. The Bridge itself is, 99 percent of the time, not even operational. The things that are of value are the certificates it issues, and where those certificates are placed, mainly in directories.
I issue cross-certificates to a bunch of parties. You have those cross-certificates. If the Bridge blew up tomorrow, it wouldn't matter. You've got the cross-certificates. The only thing that is important to you are those cross-certificates, and the revocations lists that say that those cross-certificates have not been revoked.
We believe very firmly in that regard that the Bridge is going to issue no more than in my wildest dreams, a couple hundred certificates. The revocation lists that the Bridge issues better be the null set, or else I would have to revoke a principal CA of an agency, which would be sort of a disaster must have occurred at that agency.
So it's a very stable model in those terms. I won't bore you with the details here, but I would go beyond that and say it is not susceptible to denial of service attack. It is not susceptible to intrusion attack either. It is not networked to anything. Only the Bridge directory is networked. And the only thing in the Bridge directory is signed objects.
So we have had NSA look at this. We are very confident that the model is a robust model from a security standpoint, as well as from a policy standpoint.
DR. COHN: Kepa, you are the last question. I want to make a comment, and then we're going to give everybody a break.
DR. ZUBELDIA: You've got me sold. I know it's encouraging, the fact that you mentioned the four essential elements, the Bridge policies, certificate policies, the actor profile, and certificate profile as being the essential elements here. And with interoperability pilot we had last year, except for the Bridge policies, because we had a Bridge CA instead of a Bridge.
We have a report that came out a couple of weeks ago on the directory profile, a certificate profile, and agreed certificate policies for that project in health care. So at least there is some common thought there. As part of disclosure, I need to say that I was coordinating that interoperability pilot with the FA(?).
The question I have is how can health care plug into the bridge? I assume -- this may be a presumptuous assumption -- that HHS and HCFA, as government entities, could fit into the federal PKI bridge by themselves. But what we need to do is plug in the rest of health care, and the states that have authority for prescriptions and other health care things into some Bridge.
Would that be the federal PKI Bridge? Would that be a separate health care Bridge under maybe what the HealthKey project is putting together with Mitretek? How would you plug the health care industry, not just HHS and HCFA, into a Bridge that could also allow HHS and HCFA, which I assume would maybe become part of the federal Bridge, to interface with this health care Bridge, and have it all coordinated under one system?
MR. GUIDA: That's an excellent question, and let me mention before I even answer it briefly, I had the pleasure of meeting Kepa for the first time about six months or so ago. And it was one of these experiences like the prodigal sons. I had been following through e-mail, a lot of the things he was doing with his pilot effort, but I had never found the time to really delve into some of the things in detail.
Then finally I had the pleasure of meeting such a wonderful person. And lo and behold, he was doing all of the same things that I was doing. And I took great solace in the fact we were both confronting similar problems, just as he described, and we had come to pretty much similar conclusions. Or at least we were facing the same issues in the same fashion. So that said either we were both out to lunch, or we were both on the same wavelength. But in any event, it could be the former, but we actually had lunch, we were both out to lunch, I guess at the same time.
Okay, to answer your question, Kepa, I think that the this approach is it provides for multiple ways to get people working together. For example, indeed HHS and/or HCFA and/or NIH, any of the above, will cross-certify as some point, when they are ready to, with the Bridge. But the interesting thing there is it doesn't just have to be HHS.
We already have situations where I expect some subordinate, some subdepartmental agencies will cross-certify with the Bridge, with the agreement of the parent agency. We are not going to allow subordinate element X to cross-certify with the Bridge unless the parent says he can, or she can. But if they say they can, no problem, we allow that.
So in that sense, first, you're right that the Bridge initially is focused on just the federal agencies. If you look in the Bridge certificate policy, however, it says explicitly it is our intention to cross-certify with external elements. And that will be a decision made by the policy authority when that is to occur. I don't control that. There will be a lot of liability issues that will have to be addressed at that time.
Right now liability is a wash when federal agencies cross-certify with the Bridge. As much as they might like to sue one another, they can't. And so as a consequence, there is no liability issue. As soon as they get somebody else, there is an issue.
So I see two possible solutions, or maybe three possible approaches. One approach is the health care enterprise, just as being done here with North Carolina and Minnesota, a very laudable effort, you develop your own Bridge. Everybody or a lot of entities cross-certify into that Bridge, and that becomes your Bridge of interoperability for health care providers and health care activities. And then what do we do? We cross-certify your Bridge with our Bridge. And now suddenly we have PKI connectivity that is profound.
The second approach, for those parts of the health care community who do not wish to participate in the health care Bridge, but do want to deal with HCFA or something, they can cross-certify with a HCFA CA or with an HHS CA. Once again, I now have topological connectivity between other agencies of government and these companies; not with these companies being subordinate to -- I'm talking across certificate now, between the company and between a HCFA or an HHS CA. We now have topological connectivity in that fashion.
The final approach is just direct certification with the Bridge itself. Company X, Kaiser Permanente, whatever, decides they would like to cross-certify with the Bridge. Would the policy authorities say no, we're not going to entertain that? Absolutely not. I mean I know the policy authority is thinking at least at this stage, and they would entertain a request for cross-certification from anyone.
Now I can't tell you how quickly they would honor it. We still will have our production version of the Bridge operational, obviously. As I say, we're still in the death of a thousand continuing resolutions. But my hope is by early next year we'll have all of that settled. We will have the production Bridge operational, we'll have the policy authority to point where it has -- we are actually working on it, to tell you.
We have an application form that we are working on, a standard memorandum of agreement that we are working. A trial guide to what does it take to cross-certify with the Bridge that we are working on. All of these things that are in draft today, and that the policy authority is either reviewing or will be reviewing in due course.
I should mention, by the way, there are six members of the policy authority, six charter members. The charter members are: DOD, Justice, Treasury, Commerce, GSA, and OMB. Other members will join once they are authorized to cross-certify. Once they apply for and are authorized to cross-certify with the Bridge. We had to pick six charter members obviously, because you've got to start somewhere, right there at the boundary condition.
So the simple answer to your question, Kepa, and I apologize for making this so long winded, but I think that there are multiple ways in which cross-certification interoperability can be affected, ranging from the profound, you just cross-certify directly with the Bridge. To you cross-certify Bridges, we did that. We tested that. The DOD Bridge to the federal Bridge worked. To cross-certifying with an agency CA, which then gets you to the Bridge if that agency CA is cross-certified.
You can imagine in each of these cases there are pros and cons. If you cross-certify directly with the federal Bridge, then regardless of what happens to your own Bridge, you are still going to interoperate with the federal government. And I'm not proposing that everybody should do this. I'm just observing that the more links in the chain, any link goes back you are disconnected.
Now that having been said, I do think it's efficient to have Bridges bridging. I like the idea of the Bridges cross-certifying among themselves. I do think that's a very sweet technical solution.
MR. LYNCH: Could I make one response too? I would to see this as a challenge for NCVHS to bring together certain parties. In Connecticut we've got a large VA in West Haven, for example. The VA might have its own components. We heard yesterday about the DEA. We would love to NCVHS bring together the VA, the DEA, the pilot from HealthKey, whatever, and try to see if we can't make this happen for health care.
DR. COHN: Well, there is no way that I can make a comment in 45 second that tries to summarize all of what has been said over the last two hours. I first of all want to thank the panelists for a fascinating and thought provoking set of discussions.
Certainly, we talked about interoperability yesterday as one of the big issues, and we certainly had an in depth look at many of the issues around that. I would also observe that obviously I think we're seeing sort of over and over again that there are technical pieces here. There are policy pieces.
After all that is said and done, there are obviously a whole bunch of education pieces. Because you can put together all the technical and policy pieces you want to, and if people do whatever they are doing, and not abiding by all this, obviously, trust is destroyed at every part of the whole thing.
Certainly I am sort of struck that the policy pieces are really profound. And I'm reminded in some ways as I listened to mapping, I'm sort of reminded of terminology mapping frameworks that we've done, which is very similar to also the GCPR, which is attempting to map. And Richard, I agree with you, the devil is in the detail here, because on a high level it sounds great. Trying to get data and concepts that really do map well across, is just an incredible issue. You can get sorta kinda without too much trouble.
MR. GUIDA: What that says is we've got to stop talking in English. If we just talked in Fortran, it would be easy to do this.
DR. COHN: Yes, except for those of us who talk in Cobalt or Basic.
MR. GUIDA: Even there, they are all computer languages, and they are context free. Whereas, any languages are context sensitive.
DR. COHN: I'm going to stay away from this particular discussion. I do want to bring for 15 minutes. Richard, I'm sure that we are going to take you up on your offer of providing us additional information. I don't know what that is yet. I think we'll talk about that probably in the next session when we are just sort of talking about next steps.
I really want to thank the whole panel for really a fascinating and useful discussion. So thank you.
MR. GUIDA: Thank you very much for the opportunity.
DR. COHN: We'll break for 15 minutes.
[Brief recess.]
Agenda Item: Discussion and Future Plans
DR. COHN: Now we are going to be doing two things during this last session. This is not a time for presentations, thankfully. It's really a time for the subcommittee to decide really what the next steps are. We certainly welcome any input from the panelists. We hope we can sort of take about a half an hour to do that.
And then we're going to sort of shift gears a little bit and talk about the overall activities of the subcommittee over the next year, and some hearing planning issues. I hope we move from the trees this morning, up to the forest now, and then move up into a lower continental view as we finish off, and hopefully adjourning by around 12:30 p.m.
With that, shall we talk a little bit about what we need to do, and our thoughts at this point.
DR. ZUBELDIA: From these two days I'm getting the impression that we need some of what we discussed last night. We need some very specific implementation guides that can be adopted by the industry that would provide interoperability. I think they will have to contain components like how do you sign something.
MR. BLAIR: Can we back up for second. We didn't know what you did discuss last night.
DR. ZUBELDIA: Here in the subcommittee.
MR. BLAIR: Last night? Oh, you meant yesterday afternoon.
DR. ZUBELDIA: Yesterday afternoon, sorry. So we have very specific interoperability components. I also think we need some policies that have to be agreed to by the industry, and maybe all we can do there is have some generic, independent policies that say these are the minimum requirements to identify an individual.
An e-mail address is not enough. You need to have something beyond an e-mail address. What are those are requirements? Minimum requirements to authenticate an institution. And what are those requirements? And have some generic policies in that area that will then have to be implemented by the industry. They will be technology-independent.
Maybe the industry can reach a consensus on the implementation of those policies. But I don't know if the industry is ready for that yet. But for the very specific implementation of signatures, that would insure the interoperability, and the fact that when I sign something here, and when I send it across the street, somebody else can verify it without having to install 20 different software packages on their PCs.
I think that that process should be very well defined, and also very well scoped, like it was pointed out yesterday. Maybe since we are kind of limited by HIPAA to transactions, you say okay, this is how you do signatures for the transactions. And we are adopting an industry-driven, consensus-driven implementation guide on how to do signatures for the transactions.
Now understanding that today we have X12 and NCDP transactions. But in a few months or years we will also have maybe prescriptions, maybe medical records from HL7, other transactions. And those may have different implementation guides, maybe not. We don't know yet.
MR. BLAIR: Or may I add, even beyond messages, documents.
DR. ZUBELDIA: Documents. But I don't think that's the scope of HIPAA today. But I think that within today's scope we could have the recommendation to adopt something very specific and well defined. But also the technology is not enough. All the policies surrounding it are very important. And maybe some experts like the PKI Bridge can bring in their expertise with those policies as to how would that work, and NIST. And we have to work with the Department of Commerce, so I would get their experts on the subject, because they do have experts.
DR. COHN: Well, certainly Kepa you are right. As I review the legislation again, it sort of speaks of the secretary in coordination with the secretary of commerce shall adopt standards specifying procedures for electronic transmission and authentication of signatures. I don't know who the right people are from Commerce. But I didn't think of Richard either as a representative of some of that view. It would be nice to have people from NIST and the Department of Commerce nodding their heads also. Which because of the legislation, we have to get their sign off on whatever it is.
MR. GUIDA: Bill Burr is one person, but we have worked extremely closely with them. They are completely in bed with the certificate policy, with the Bridge functionality. As you saw on my chart, they actually had two of the CAs that cross-certified with the Bridge as part of our test. I look at the PKI cognicenti within the federal government as the NSA, NIST, GSA, and some of us in Treasury. Not that the others aren't doing good things, but we're the ones who are really trying to help make it work interoperably more than that's our job. That's our focus.
So I can give you plenty of names there. I think you will find that they are singing from exactly the same sheet of music as what I have just described here. I should also mention that I am a member of the CSSPAB, the Computer Systems Security and Privacy Advisory Board in the Department of Commerce. So I'm not here representing the CSSPAB, but I know what the CSSPAB is doing as well. And they likewise are on the same wavelength that I have just described.
DR. ZUBELDIA: There is a question that is lingering, and that was brought by John this morning as to what is the role of NCVHS? Should NCVHS be accrediting the CAs? Should NCVHS have any involvement with the Bridge directly? Personally, I think that should not be in the NCVHS. But somebody needs to be build that trust by accrediting CAs, and accrediting the policies.
Maybe the HIPAA police -- I understand that Dr. Braithwaite has a badge now for the HIPAA police -- maybe the HIPAA police should have that role to accredit certificate policies and accredit CAs, and say who can participate in the Bridge, and who can be cross-certified, and at what level.
MR. BLAIR: Our committee is fortunate to have two people who pretty well are considered experts in this area. I guess I would like to hear from the other expert, and that's Kathleen, in terms of her thoughts on where we can go from here.
MS. FRAWLEY: I think our role is fairly clear in terms of some of our discussion yesterday afternoon and this morning. I think that we know there is a need for clarity of definitions for the industry. We know that we need to come up with some requirements, and also some guidelines for policies for the industry. I think that falls within our role as the public advisory body to the secretary, to make recommendations in this area.
I don't see us certifying entities or going beyond our scope as outlined in the charter. But I do think that if we can at least give more guidance to the industry in terms of what the requirements are, what we think are appropriate standards, and move in that direction, I think that would be helpful.
I think that we also probably need to coordinate with some of the standards development organizations, and let them know what we are thinking, because certainly no one has probably said to any of them, we need implementation guides. I think that's something that people need to hear. They have been doing work in this area. That that would be useful to industry.
So I think there are some messages that we could convey to the SDOs whether we go through NCHISD or whether we go directly to the different SDOs who have done work in this area. It would be helpful. So I think that there are a number of steps that we could take which would involve a lot of work going on outside of this subcommittee and the full committee, but with the expectation that hopefully in a couple of months we could get some progress reports from some of the work that is going out in the SDOs.
And at the same time, some of the information that they will provide to us, plus some of the existing work that has already been done that we could be looking at in terms of developing some of our recommendations in terms of definitions, requirements, specifications, guidelines, model policies, and so forth.
DR. COHN: I actually agree with your comment about the role of this committee is not to accredit CAs. It may be to recommend that the secretary put together a process to accredit CAs, but I think that's the limit of our responsibility, and that's certainly enough.
Now having said, and we'll talk about the future activities of the subcommittee, but I think it would make sense in all of this, since we are really talking about digital signatures for transactions, we're not talking about just for any sort of clinical information, but really we are looking at the world of data moving around in view of specified transactions coming from standards development organizations.
Including when I asked them early on about what would work well. And we heard that yesterday, sort of saying well, gee, if you were talking about X12, you would to talk to X12, HL7, NCPDP, et cetera to find out their views before any decisions were made. And that maybe in January may be a reasonable time to begin to ask them for some of their views. Certainly, the better the questions we can posit, the better off we will be. That's sort of my thought.
MS. TRUDEL: I just want to supply a little bit of the department's perspective here. When we initially published the proposed, it included both security and electronic signature standards. And in developing the final security rule we have removed the electronic signature requirements, but that doesn't mean we stopped working on them.
We do have comments that we received on the regulation. We have a regulation team that is interagency, and does include industry representatives. And they are continuing to meet and discuss issues and ponder where to go. So I think that any ultimate recommendations would find their way to that group, and I'm sure they would be happy for directions.
I think Barbara Clark, who is lead of the group, has been sitting through the hearings for both days, and I think we have a lot to take back with us and think about. But we will continue to work, and would appreciate any recommendations the subcommittee might have.
MR. ANDERSON: I just want to point out to the committee that the one thing that brought the North Carolina community together 15 months ago to form a HIPAA implementation planning task force was the issue of interoperability of inter-enterprise networking solutions, where there are more than 20,000 different entities in the state. If each one purchased a system from a vendor purporting to be compliant, and if there were no way to certify or test or benchmark those systems, the industry, including small practices and everyone else could be at a substantial disadvantage.
So we are continuing to look at how to certify and do that. We are hoping that there will be a national solution or a resource where people could go and benchmark a system, or whether there could be a certification site. There is an approved list of vendors that could be selected by any practice or any hospital or any health plan, and have some sense of interoperability.
And whether that is a NIST-like effort, or an ENAC(?) like effort, we would encourage that. That would be very helpful to the states and the entities there.
DR. COHN: Holt, just to respond to you, and then I'll let Kathleen comment. Actually, the subcommittee and full committee are already on record as recognizing the need for -- not the need, but the issues around HIPAA compliance, and the vagaries associated with that. Now we started with the administrative and the financial transactions. I don't think there is anything in our recommendations about that is just limited to that. We share your concern.
MR. ANDERSON: And we recognize there are some end dates in mind that we are thinking in terms of end of 2002, and realizing that we need to implement somewhere a year ahead of time to begin testing. So that the timeframe is --
DR. COHN: Okay, well, let me also speak, and I think I'm speaking for the HHS representatives here. Be aware that the digital signature aspects of the final regulations are being delayed. They are not going to be out as part of the security final rules.
MR. ANDERSON: That means we don't need to worry about protecting data?
DR. COHN: Who would like to answer that? I'm just reporting to you the facts.
DR. ZUBELDIA: Holt, those are the security regulations. The security regulations are not going to be delayed much. The digital signature is decoupled from security. That will come later.
MR. ANDERSON: I hope you're not suggesting that this is a pioneer electronics project, that we buy a piece now, and another piece later, and another later.
DR. COHN: Let me address your concern. I mean the subcommittee and full committee are obviously concerned about this. This is why we are having these hearings, to try to get this back on track, because we think it's important.
Kathleen?
MS. FRAWLEY: Just going back to the comment you made about the SDOs in January. We might want to speed up some communication to the SDOs. The reason for that is ASTM will be holding its full meeting in conjunction with AMIA in Los Angeles in a few weeks. NCPDP I believe is meeting in December. HL7 typically has its winter meeting in January. So if we are going to be expecting -- and then we've got X12 too.
So if we want these people to start doing things, we need to let them know right away, because ASTM is meeting in two weeks, you don't want to have a group coming together, and then after the meeting is over, it's very hard to work between meetings, as we all know. So my only concern would be is that perhaps the one thing we should do after we leave here today would be to get a letter out to those organizations, letting them know.
It could be a phone call, whatever Simon thinks is appropriate. But I think the sooner the communication, that will help those groups that are meeting to at least make room on their agenda to discuss some of these issues.
DR. COHN: I think if we decide at the end of the meeting today that this is the course we want to take, I think there can be a conversation followed up obviously by a letter. The letter may take more the form of inviting to testify and comment on certain issues of which this is going to clearly be one.
So maybe not a formal letter going through the NCVHS. It has be balloted, but more along the lines of we are considering these issues. We want your input. Come to our next hearing and provide us some input. Does that sound reasonable to you, Kathleen?
MS. FRAWLEY: No, I'm thinking more of a heads up. You're having a meeting next week or in two weeks or next month, and we recognize that you have standards out there in this area. And the subcommittee recognizes the need for implementation guides. You might want to start thinking about a strategy to develop them. At least giving them --
DR. COHN: I guess I'm thinking it's premature to start asking standards organizations to develop implementation guides until we have identified which standards you want to accept. I am reminded by our conversation yesterday that one of the wonderful things about standards is that there are so many of them. That's my view. I'm just one member of this subcommittee. Do others have comments?
DR. ZUBELDIA: I kind of agree with Kathleen. I would like to get them moving in that direction as soon as possible. There is something though that needs to happen if they are going to move in that direction. They need to work together. And I would like to see ASTM working together with X12C, which is the security and syntax part of X12. And working together with NCPDP security group, and with the Internet Engineering Task Force that put together the Internet security standards.
And have those SDOs that are involved in security transactions getting together, to at least start talking to each other about what is it that we need to do, and what is out there that will work for everybody.
MS. FRAWLEY: Well, I mean that could come from HISB. That's the other way to approach it. And I don't know when the next HISB meeting is.
DR. COHN: December 6.
MS. FRAWLEY: There are ways to achieve that. I just think that the sooner we can let the SDOs know kind of what our thinking is. Some people here belong to some of those organizations, and I'm sure information will flow back. But I just think that when we were looking at the administrative and financial transactions, the SDOs really understood what we were doing, and where we were headed, and the value of the implementations guides, and why all of this was very important.
So it made our recommendations a lot easier when it came time to bite the bullet and say, okay, here we go. This is what we're recommending. At some point we are going to have to sit down and say, okay, here is the menu of standards that we think should be adopted. Obviously, it's going to make it a lot easier if the SDOs kind of know what some of the early thinking is.
Some SDOs may choose not to develop implementation guides, or not try to put any energy into some of the work they have already done, and other groups may decide to move to the forefront. So that's my only recommendation. I just wouldn't want us to wait until our next meeting. Then it will be spring before we start to see any movement.
DR. COHN: Is your comment on this issue?
DR. GREBERMAN: On this one specifically though I think it is important to let the SDOs know early on in the game. But I think really is on my mind also is one thing that came out in our discussion, is not all of us were very clear what all the SDOs were doing. And would it be useful to at least start thinking about another set of meetings that would involve them, so we could sit down and hear what they have to say, and be able to compare one against the other and discuss them in an organized way, like we have learned so much around this table.
MR. BLAIR: As I mentioned before, the last time I looked for example at the ASTM document, it was either three or four years ago. And when Jan LaVerne came up here -- I don't know if she is still here or not -- I asked us if she could get us current copies, because I think that at this stage the committee members need to become familiar with that.
But apparently there is a whole bunch of other standards that we have to be familiar with as well. The FIPS(?) and the secure wrapper for HL7, and whatever security aspects there are that I'm not even aware that Kepa maybe you could point out to us with respect to X12, or any others. Between maybe Kepa and Kathleen, maybe you could pull together a list of the documents that the committee members frankly need to read, so that we could not be as ignorant as I am right now.
DR. ZUBELDIA: There are between half a dozen and a dozen documents. ASTM has some excellent documents, X12.58 is another one, the EDI ENT(?), the HL7 structures. There are about maybe 10 documents. And we can put together a list, and try to get them together for the committee.
MR. BLAIR: That would be very helpful.
DR. COHN: I'm afraid that we are wandering off, and I want to come back to this issue, but Richard, are you commenting on this particular issue?
MR. GUIDA: Yes, indeed. I can make available the FIPS -- there are several, as you said. The FIPS standard is a relevant one, 140-1, actually -2 now. FIPS 186, which is the digital signature standard. The certificate of policy, I already promised, and I'll get that to you. I'm happy to get you anything that I can, and you can decide what you would do with it.
MR. BLAIR: I think Dave Barnett mentioned a number of standards that were very helpful to him when he testified yesterday morning. Dave, are you still here?
DR. COHN: No.
MR. BLAIR: Oh, okay.
DR. COHN: In the testimony, they are all listed. Karen, are you talking about the things that we need to read, or are you talking about preparing for our next meeting.
MS. TRUDEL: It sounds as if some of this activity might be more appropriately done by the department work group that has been doing a lot of the research and developing these rules. I would suggest that when the subcommittee decides on a course of action, the ultimate target be recommendations back to the work group through the secretary.
And if that recommendation is we think you ought to go out and do some more research on X, Y, Z, or we think you ought to go out and talk to the SDOs, I think those are reasonable recommendations. Or possibly hearing some additional testimony would be appropriate. But it sounds as if there are some decisions being made here about what the final goal is, final decision.
DR. COHN: I think you are addressing some of the issues that I'm sitting here grappling with, which is sort of what are the next steps. And that's opposed to what is the final goal. We at some point, need to come out with a letter advising the secretary of our recommendations. I think we have overall identified that it makes sense to be more specific as opposed to less specific.
We have also, I believe, identified that we should leverage as much as possible, the expertise of the SDOs, recognizing that they are developers of standards, as well as they are users of standards. And so we really do need to early on, enlist their advice and guidance in both what they have developed, as well as what they are using, and what they would recommend be used.
And so I think that's really a lot of the focus of what we need to be doing. I'm positing January, because I'm also thinking that probably the SDOs and the DSMOs are going to be wanting to come forward to us with new and revised standards in January. So that becomes a very reasonable time to also ask them these questions.
MR. BLAIR: A point of clarification?
DR. COHN: Yes, let me just finish, and then I will allow you to clarify. I think what I'm hearing from everybody is we need to let them know early, both in verbal and written form as soon as possible, that we are interested in this area and need their advice and guidance.
And sort of following up on what Kepa was describing, which is we would ideally like them to work together. The fewer standards that come out, the better. And the more agreement around a single or a few standards would make everybody's life easier. It would be nice to have them work together, and probably we need to specifically communicate in addition to the individual SDOs, also to NCHISB, because they are a useful forum where the standards organizations come together.
That's as far as I have gotten. Question, clarification, Jeff?
MR. BLAIR: Yes, thank you. My understanding was, and I'd like clarification if this understanding is not correct, I thought that we had been gravitating towards sort of a two tiered approach. One tier is that we look for common standards for policies that are across the board, requirements and definitions that are across the board. And then in addition to that, we look for drilling that down, driving that down to implementable standards in certain specific areas, whether that is electronic patient records, or whether that is drug transactions or whether that might even be for financial/administrative transactions.
But that was my understanding. I don't have to repeat it. In a sense it's a two tier, and we're looking for specific implementations within the overall common policies, requirements, and definitions. Is that not correct?
DR. COHN: Well, I'll ask others. I'm not sure that's my understanding. Kepa, what is your comment?
DR. ZUBELDIA: I think Jeff is correct. There are two things that we are looking for. One is general policies to provide security and authentication of technology that can be implemented by different entities in their own way, but that would say what are the general requirements for health care, and what are the minimum requirements for health care.
And then a specific implementation of signatures for use with the health care transactions in HIPAA. And that specific implementation of signatures should be an implementation guide adopted by the consensus process by the SDOs. An implementation guide should be open to implementation by anybody who wants to implement it for the HIPAA signatures.
DR. COHN: Other comments about understanding what we want? Kepa, a number of people are agreeing with your view on that. Jeff, does that help?
MR. BLAIR: Thank you.
DR. COHN: Does that change in any way what I was describing as the sort of the issues and next steps around all of this? Is there anything else we need to be doing about all of these next steps? No?
DR. ZUBELDIA: I think we need to talk to the standards setting organizations, and getting them to work. And then recommend to the secretary that the standards adopted by standards setting organizations be adopted by the secretary under HIPAA as the signature standard. And there are probably some standards setting organizations for policies.
I don't know if that's the Federal PKI Bridge or NIST or some other standards setting organization that had defined policies, and have them look at health care-specific policies. And maybe adopt those as HIPAA standard policies, or recommend the adoption of those. I don't know if that analysis it probably should be done by the department rather than by us.
DR. COHN: And certainly I think we heard today, as well as yesterday, a bunch of industry standard standards that are not health care specific, but provide the foundations for a lot of this. There is no question of whether they are already being referenced in some of the other standards. There are health care-specific standards is the part that I think we need to understand better.
DR. ZUBELDIA: I would add something else. And it's not only we should have a standard to recommend to the secretary for adoption. I would like to recommend that HCFA adopt the standard and lead the way, the same as we have recommended for the electronic medical record, that the department leads the way. Maybe HCFA can lead the way in adopting the standards under HIPAA, or just for Medicare. I know that's going out on a limb --
DR. COHN: Let's figure out what we are doing first, before we figure out who should be implementing.
DR. FITZMAURICE: Just as an adjunct, what you could advocate is HCFA investigate pilot possibilities. The possibility of doing pilots in this area.
DR. COHN: Yes, that would probably be fine.
MS. TRUDEL: Let me just get back to the process here, because this is a federal advisory committee. And it's my understanding that the appropriate activities are making recommendations to the secretary, or information finding and hearings that lead to recommendations being made to the secretary. And those are the two appropriate courses of action.
And I'm not sure which one I'm hearing that the committee wants to follow in the short-term. Are we talking about hearings in January to discuss some of these SDO issues? Or are we talking about making recommendations to the secretary at this time? I'm just a little confused. I think we are talking about hearings in January, and that we are telling the SDOs that these issues came up. We would like them to come in and talk with us. They might want to think and talk amongst themselves prior to that time. Is that correct?
MR. BLAIR: Yes, and I would think that we're not probably prepared to make any recommendations until after we have done our own reading and homework, and we've had the testimony in January. And then after that, I think we can talk amongst ourselves so to speak, on the committee, to see if there is a consensus or a convergence on recommendations which might be in later January or early February.
DR. COHN: Is everybody nodding their head? Kathleen?
MS. FRAWLEY: The full committee doesn't meet again until February. I doubt we would even have a recommendation for the full committee at the February meeting. Then our next meeting would be June. But we do have a process obviously about how a committee works between meetings in order to develop consensus on recommendations to the secretary.
I see it as we are giving notice to the SDOs and HISP, here is our thinking. We would like you to come in January. Obviously as Jeff said, we need to do some homework ourselves, because there are different knowledge levels among the members of the subcommittee. And we in turn, have to be as educated as we can in order to present our recommendations to the full committee. Because then we have 12 other people relying on our judgment in order to make a series of recommendations to the secretary.
So I don't see, in terms of our timeframe, certainly it's not going to be until spring before we would be in a position to make any recommendations to the full committee, and then obviously onto the secretary.
DR. COHN: Do you February is spring?
MS. FRAWLEY: No. February is too early. I mean if we have the SDOs talking to us in January, I just don't think we're going to be in a position to make any recommendations in February, unless we have a eureka moment during the hearings.
MR. BLAIR: There might be great consensus. Maybe a miracle will happen.
DR. COHN: I'm an optimist, and I'm always willing to accept that eureka moment. I don't count on it, but certainly if there is a eureka moment that occurs in January, I think we should leverage it. Certainly I don't think that there is a letter coming out of today. But I think that when we sense there is consensus, as well as have some enlightenment, then we need to send a letter to the secretary recommending it.
MS. FRAWLEY: I think that one of the things that we have to think about for our February subcommittee meeting is we hear from the SDOs in January. We're going to have a subcommittee meeting in February. I think the strategy we used when we were adopting the administrative and financial transactions was then hearing from industry. So our February meeting could be the industry to come forward and weigh in. And I think that would be the way we need to go.
We felt very comfortable when we were adopting the X12 standards. We must have heard from 40 or 50 people, and it was like everyone was coming into the room, and in consensus, and very much in agreement that that was the appropriate approach for us to go. And I think we felt very comfortable when we made our recommendations.
But I would feel uncomfortable hearing from the SDOs, and then just jumping forward to a series of recommendations, without giving industry the opportunity to come forward and weigh in.
DR. COHN: Thank you for observing that important process. Of course we just spent the last day and a half with the industry. But I think you are right, we do need to loop back after we have something more definite. What we have heard over the last day and a half is there is an issue, and it's not something that should wait until some time to be determined. But we really need to get this resolved.
Comments?
MS. BURKE-BEBEE: Actually, a question. Thinking of what Kepa had said, and again, what Karen had said about what the role is for NCHS being advisory, but at the same the work is going on, and there is a law that is in place that was referred to a little bit by Rich, GPEA, Government Paperwork Elimination Act. And I was wondering, it does involve the electronic signature. And it does require that government agencies by 2003, have something in place dealing with electronic signatures.
Thinking of HCFA being a leader in that area, possibly seeing what they are doing as far as electronic signatures. When we talk about the SDOs, the standard development organizations, and what they are doing to develop implementation guides or whatever, what actually is going on to implement the standards? What are the standards, and what is going on to implement those standards even as the SDOs are developing their own standards?
MR. GUIDA: If I make a point on that. Suzie is exactly correct. The deadline is October 2003. But in advance of that, there is a deadline at the end of this month, I believe it's October 31, for each of the agencies to report to OMB on their progress in implementing GPEA. And this is partly OMB's effort to see that you don't come up to the edge of the cliff and then suddenly decide that everybody forgot to do something. They are actually trying to reasonably have agencies report on how they are getting ready to be in compliance by October 2003.
I don't know what HHS's report is going to look like. I know that in Treasury we have gone through a lot of reviews of this thing, because we do not want to say things like, well, we don't think we're going to make the deadline, for the following 15 transactions, because we know that will draw the opprobrium of people who we would prefer not to have the opprobrium drawn from.
So my point to all this is if HHS -- they must have a report. The report is probably close to completion. Once it is completed, that will tell the story as to what HHS plans. And I don't know whether HCFA has a separate report, or whether HCFA is reported underneath the HHS. I know that in Treasury the bureaus all are reported underneath the Treasury report.
MS. TRUDEL: I believe the HCFA report is rolled into the HHS report. But remember again, the transactions that we are talking about with respect to health care are these same transactions for which the SDOs cited there was no need for an electronic signature. And currently, we do EDI in Medicare without electronic signature. But we do quite a bit of it, and we anticipate that we'll continue to do that.
MR. GUIDA: But the issue there is not what the -- the SDOs, I assume, for the acronym is standards development organizations. The issue with GPEA is not what the SDOs think. The issue with GPEA is what do your trading partners think. If you have a trading partner who wants to use an electronic signature with you, the federal agency, if there are more than 50,000 copies of the form are received in the period of a year, you are compelled, unless you have certain extenuating circumstances, to be able to accept the form in electronic fashion, and with an electronic signature by October 2003.
It's not what the standards development organizations think or don't think. It's what your trading partners think.
MS. TRUDEL: I think we're getting off the topic here. I think this is a non-issue in terms of what we are discussing.
MR. GUIDA: It will be interesting to see what the report says.
DR. COHN: Certainly, somebody should review the report, and I'm looking at you, Karen, or Suzie. If there is anything that is pertinent to this discussion, we can bring it forward. We are not beating a dead horse yet, but I think we have come up really with what are the next steps, I think.
Which is we'll talk next about we'll begin to move off -- I've got pieces that have to do with issues that we need to be dealing with over the next year. I think we are saying in January we want to hear from the SDOs, what their thoughts are around all of this. And hopefully, we'll be able to capture that information in the overall context of having them come and talk about changes to standards, and otherwise for upcoming years.
And that we want to communicate with them as early as possible. And we also want the view of NCHISB, and subsequent to that, we will obviously need to also loop back around and hear from industry again. Have we synthesized that one?
Okay, now I want to pass this around. I will apologize, I didn't make copies enough for everybody in the audience. These are just issues, and this is sort of a draft document, so I was a little embarrassed to make copies to go all around.
I just wanted to review with everybody -- and I guess I should say is there anything on that for the moment, or have we summarized our next steps from all of this pretty well? Okay, good. The horse died, good.
And I just want to observe that over the next unknown number of months I will identify that there were seven major issues that we were tracking or needed to be dealing with, just to get an idea. I think you were thinking about moving to Washington, DC and you were a member of the subcommittee, this might be a good time.
The first issue of course is tracking implementation of the HIPAA standards, the financial, administrative, the security standards and identifiers, some of which are out, others of which hopefully will be coming out. And this is certainly a responsibility of the subcommittee.
And probably as we look through all seven, the first issue is have we forgotten anything? And then the question gets to be is looking at the hearing dates, and then talking about the November breakout that we'll have. So anyway, that's number one.
Number two is this issue of changes and updates to current standards and new standards, e.g., for supportive injury, possibly other standards. Kepa had mentioned prescription as something I think he would personally like to see coming forward. But we'll have to see, obviously this is more of a report from the standards maintenance organizations as to changes and updates.
Kepa, do you have a comment on that?
DR. ZUBELDIA: Yes, there is specifically another one coming from X12 on the coordination of benefits, and it's related to 69, verification between payers for coordination of benefits.
DR. COHN: That's right. I presume that this is going to be coming from the DSMOs, so I think rather than possibly others, probably others.
The third piece is the piece that we are talking about today, which is electronic signature. I think we have identified that we want, as soon as possible, to come out with a recommendation, and get the process once again actively moving towards coming to final resolution around standards for digital signature in health care.
The next piece is enforcement and compliance, which we will be needing to deal with next year at some point. And I expect that to be a notice of proposed rulemaking, and probably we'll want to hold hearings before that becomes a notice of proposed rulemaking.
Issue number five is patient medical record information standards, the MRI standards that Jeff is taking the lead on. I think that we will be needing to do some activity in that in the early part of next year.
Item number six is code set issues, including open maintenance issues. We received a letter from a number of different organizations expressing concern about some of the practices of code set developers, and whether their processes are open enough. I think there has been a letter that has been returned from HHS saying that there is going to be a survey that will take place, and based on the results of that survey, we'll be looking at that and making a decision about what we ought to be doing as next steps into next year.
Then there is ICD-10-CM, not to necessarily endorse it at this point, but get more information about the current status.
Medical device codes, which were brought up earlier in the year, and we decided to defer until the year 2001. And of course others to be determined. There are lots of code sets out there.
Kepa, have I missed any?
DR. ZUBELDIA: There is maybe among the others to be determined, there is an issue that is creating great turmoil right now. That is the mapping between NDC codes and J codes. And we probably should take a look at that, and see what is happening there. Because they are saying that NDC codes should only be used for retail pharmacy, and they should not be used for medical. And there is a lot of turmoil going on.
MR. BLAIR: On the code set one, were you thinking of code sets that were in support of the X12 and NCPDP transactions? Or were you thinking of code sets across -- I wasn't sure what you were thinking of, or the ones related to local codes? What were you thinking of?
DR. COHN: Well, I actually just mentioned what I thought were the issues that we had on code sets, but I'm sure there are others.
MR. BLAIR: Oh, I'm sorry, you mean they were subsets like the NDC codes, conversion to the J codes?
DR. COHN: Well, that was just added as an item that he might want to follow-up on. Code sets, we could spend our whole life in code set issues. I put down four that I thought were issues, but there may be more.
MR. BLAIR: Could you just repeat them?
DR. COHN: Sure. The issue of the openness of the updating and maintenance of the process for code sets. And by those I mean the code sets that have been selected for HIPAA standards. And then the ICD-10-CM, medical device codes. We heard there needs to be some update or discussion around the issue around NDC and J codes. And then others to be determined. And it certainly begins to become an issue in relationship to PMRI standards. I was trying to keep this one separate from that.
Anyway, item 7 is of course the general issue of letters to the full committee on upcoming NPRMs. And we will are hoping that we will some NPRMs, as well as full regulations. But we're hoping that we will see some NPRMs coming up in the next several months.
I looked at this and I wasn't depressed, but I was well aware that we actually had a fair amount on our plate. I only bring this up in the sense that we need to be careful in terms of the allotment of our time for the next several months.
MR. BLAIR: Well, we have part-time jobs away from this committee. This is a full-time job.
DR. COHN: What have we forgotten, Mike?
DR. FITZMAURICE: Just a clarifying question. On the letters for the full committee, do you mean recommendations regarding the claims attaching NPRM and the health plan idea NPRM?
DR. COHN: Yes. It's the general practice of the subcommittee on these issues to develop a letter for consideration by the full committee based on our opinions and views of that notice of proposed rule.
DR. FITZMAURICE: Before they come out, or after they come out?
DR. COHN: This is after they come out. This is after they come out, but before they are due.
DR. FITZMAURICE: So I can breath a little easier.
DR. COHN: Kathleen, do you have a comment?
MS. FRAWLEY: [Ms. Frawley did not use her mike, and was not recorded.]
DR. COHN: Well, that's great and I would welcome your leadership in that. I think that in reality a lot of this stuff is going to need to happen in a public forum. So it's really more a question of I think arranging at the appropriate time, hearings or otherwise. And probably we will let you be the lead on the evaluation of the survey results.
What we expect to see is probably early in the year some responses from concept developers about what their processes are around maintenance and updating, and we certainly need the first step to fill that.
MS. FRAWLEY: [Remarks off mike.]
DR. COHN: Great. Thank you so much. I think Kepa is tagged on the electronic signature. And I would say Jeff is the lead on PMRI next step pieces.
Now I guess I should ask, is there anything that we have missed?
MR. BLAIR: This is just a bits and a piece. One of the items is the continual follow-up on NCVHS monitoring of the implementation issues. And you tell me whether I should mention this or not, because these last couple of days earlier this week I was involved in a two day meeting with the state of New Mexico, who is struggling with these issues. Should I report on that?
DR. COHN: I think I would just ask in the interest of time if you could hold until the November meeting, if that's okay with you?
MR. BLAIR: Sure.
DR. COHN: But I think that's an ongoing issue, and we certainly need to talk about it a little bit in November. I'm just wanting to make sure at the moment that we have all the right issues, and that we haven't forgotten anything that's important.
Is there anything that I should take off of here that's not important? Let me make sure about this as we move forward.
Now the next issue I just wanted to bring up for everybody's view, because we will actually be asking Jackie to begin to check with people about possible hearing dates. As I said, I'm getting a sense that in January we are going to need to hold a hearing once again, around next steps in digital signature, and hearing from the SDOs. But I have also been hearing that that is probably the time we need to be hearing from the designated standards maintenance organizations, about changes and updates to the standards, issue number two, as well as any new standards that need to be brought forward.
MR. BLAIR: I think by that time we will have made enough progress that we would need some time to deal with some of the issues on standards of PMRI, namely the refining of criteria, and also the prioritization.
DR. COHN: Now is that hearings, or is that just a discussion?
MR. BLAIR: No, that's not hearings. I have formed out exactly what it would require on the agenda, but if you just note it down as a topic, and we'll thrash out what we'll need between now and then.
DR. COHN: Okay, and based on what that hearing looks like, we can either do it then, or we also have committee meetings in February. We can do it during the breakout, I presume.
MR. BLAIR: Well --
DR. COHN: Maybe, maybe not.
MR. BLAIR: I was thinking that for us to move forward, to be honest with you, we'll have to see. Maybe we will arrive at consensus rather quickly, but if not, I was thinking we might need a few hours in January, maybe three, and I was thinking that there would be either a conclusion or a review at the full committee hearing in February.
DR. COHN: Okay. Other sessions that I think we're going to be checking on, and once again, these are topics to be determined, mid-March, probably mid- to late April and mid- to late May I would expect one of those would be primarily devoted to PMRI next steps. If enforcement and compliance is ready to be discussed, it will probably be another issue. Then probably code sets and a variety of other things would be another issue. And of course insinuated through all of this is the issue of tracking implementation.
I realize that most people have full-time jobs, including myself. Do I have the agreement of the subcommittee that pursue these? Not these specific dates, where I have actually just sort of put question marks, but it's really more I would be asking Jackie to query with all of you, availability during those time frames.
Now that should get us through the first half of the year anyway. And actually, I'll ask Karen and Bill, since you are the main staff support, are you okay with that sort of scheduling? It's a relatively aggressive scheduling, with a lot of things.
Now just in terms of issues for the November subcommittee meeting. We've got a couple of hours in November, and I just wanted to float to you what I think are sort of the things we need to talk about. Certainly number one has already been modified, which were revisions of the letter to the secretary on digital signature. Obviously, we don't have a letter to the secretary on digital signature, unless something has happened while I was blanking out for a second.
But there is probably an update on progress, discussions with SDOs, et cetera, as well as planning for the January hearing. That is the future regulations, as well as NPRMs. We are actually expecting at that meeting to have a full panel talking about some of the issues that Lynn Gofoy(?) brought up at our last set of hearings around data issues related to some of the standards, and the ability of information systems and organizations to capture all of that data.
So I was hoping that we would be able to have a little bit of a debriefing of that, as well as an identification of next steps.
There is some discussion which I think needs to occur around claims attachments in relationship to how they are maintained and updated that probably is a big discussion item for the subcommittee, and then hopefully PMRI next steps.
Now is there anything else as we look at this that needs to be handled in November?
DR. ZUBELDIA: What are the dates?
DR. COHN: For the November full meeting?
DR. ZUBELDIA: Yes.
MS. FRAWLEY: The 27th is the executive committee meeting. The 28th and the 29th are the full committee meetings.
DR. ZUBELDIA: And it's going to be held here, or at the downtown plaza hotel?
MS. FRAWLEY: Here.
DR. ZUBELDIA: The website is wrong. The website shows 27 and 28.
DR. COHN: Thank you for catching that.
Well, I guess the question is, in this agenda, beyond the date of the meetings, is there anything else that we need to be talking about for the November meeting? Okay, well, I'll certainly leave it open. I think we will have plenty of time to handle these things, Jeff, if you have some issues you want to bring forward on PMRI. It would certainly be a good time for us to do that, especially if we would be restricting the discussion on digital signature. We'll have to have some discussions about that, about next steps.
Those are the issues that I wanted to deal with in terms of the full subcommittee, and make sure we were together for the next six or seven months. It sounds like I have agreement from the subcommittee both to the scope of the issues that we're going to be discussing, as well as likely what will be happening in January.
Are there any other issues that need to be discussed?
MR. BLAIR: A comment that I thought these last two days were very educational, very helpful. I feel like we do have a good direction to tackle a very complex and difficult issue.
DR. COHN: Okay, I want to thank the subcommittee for their forbearance. Mike?
DR. FITZMAURICE: I think we would also want to thank Kepa for all the hard work he did in identifying the issues and the right people, and the people that helped Kepa do that.
DR. ZUBELDIA: Stanley and Karen put it together.
DR. COHN: Yes, and Stanley and Karen for putting it together.
DR. FITZMAURICE: They did a great job.
DR. COHN: Exactly. I want to thank the attendees from this last panel, which was really helpful in terms of really helping to frame the issues, and remind us that we don't have the answers quite yet.
With that, why don't we adjourn, and we'll see everybody in November.
[Whereupon, the meeting was adjourned at 12:37 p.m.]