DR. MOORE: The next and last team is on security. To present that is John Parmigiani and his co-chair, who are headed down the aisle. John is from HCFA and Dennis Steinauer is from NIST. Dennis, John?
DR. PARMIGIANI: Good afternoon. I just wanted to say that our team represents a very broad spectrum of government. We have people from SSA and the department, VA, what have you. Many of them are present here today.
We have also experienced tremendous support and input from various groups and standards development organizations. After we make our presentation shortly, Dennis will be doing that, we'll be glad to answer any questions, not just the two of us, but a number of people that are out in the audience that are on the team. So hopefully we will be able to leave you today with some feeling that we know where we are going and we know what we are doing.
Dennis?
DR. STEINAUER: I don't know whether the rest of you have discovered the online broadcast of this, but I was -- this morning I was wanting to check the up-to-date schedule for the presentations. So I went into the Web page and discovered that they are -- they got a real audio broadcast going on at the same time. So I was able to literally sit at my desk, finish a couple of things on the presentation, get a couple of other things done, and hopefully not miss too much of the previous discussion. I thought it was very handy to be able to do that. I suppose the next appendectomy that I have to have is going to be real broadcast, too, so I'll get to listen to my screams.
Anyway, let me make sure I've got this set up here. What we have been charged to do through the act of course is in general terms to provide some modicum of security or to provide some standards that should provide a modicum of security for health care information in general, specifically for the systems that handle health care information and for the specific transactions, the electronic transactions that are used in the exchange of health care information and the handling of health care activities or health care delivery activities.
Then one of the other aspects of the act is to address the issue of what was called in the act electronic signatures, and I'll get back to this in a little bit, because at least where I come from, we don't talk about electronic signatures, we talk about digital signatures as a very specific technical term, and an awful lot of people probably put together in the same basket that signature that you write on the little pad down at the container store or Sears or one of those places with digital signatures, and those ar not the same thing at all. You probably should worry just about as much when you fill out one of those things.
But anyway, that is generally what our charge is. Now, what we have established as basic objectives in our activities are to first of all, try to develop what amounts to a common framework that can be used by health care providers and other players, if you will, in the whole health care arena, with respect to providing a common level or a consistent level of security that meets the requirements that may be established through the specific privacy requirements, other security requirements.
In a moment I'll define a little bit more what I mean by security. I don't mean just trying to keep private things private.
There has been a considerable amount of work that has been done over the years, and just recently actually, in providing good framework or structure that folks can use when they are trying to establish a security program for an organization or for an entire activity.
The National Research Council of course put out a report recently on the protection of health care information, and it providers a discussion of making sure that there is a consistent security framework before you run out and say, let's encrypt everything, or let's put everything behind nicely locked doors. That is the typical approach that we tend to take in providing security, rather than in looking at the overall picture and trying to provide security that makes sense in the context of what you are trying to protect and what it is you have at risk.
Also, the Office of Management and Budget for several years has provided federal government agencies with a basic structure or framework for security programs. They have recently updated that guidance to reflect a little better current technology and current network advances that have certainly affected how we look at and are concerned about security.
I have been in this area for about 30 years now. I think we spent the first 20 to 25 of it trying to get somebody interested. Now all of a sudden, all you have to do is watch TV, watch CNN, see what has happened recently, see the IDM or the other ads that spend as much time trying to point out that they indeed are trying to make things safer to conduct business and other activities, whether it is on the Internet or using information technology in general.
What we are going to try to do in this process -- as I'll point out in a minute also -- is to try to make use to the maximum extent possible existing work that has been done to existing standards or guidance that has been provided. For everyone's presence of mind, to try to identify those security processes that ought to comprise a baseline for virtually all activity that is undertaken.
One of the things that has caused managers and other folks a lot of problems in the past is spending an awful lot of time analyzing, what do I need to do, how do I need to protect this, and sometimes going through very involved risk analysis processes, which indeed are -- technically, that is the right way to do it, but sometimes you can spend so much time and effort trying to analyze it, as opposed to just doing it. There are certain activities that probably come into what the lawyers call the prudent man concept, or the prudent person concept now, that comprise a baseline. You ought to be doing these sorts of things irrespective of any long drawn-out discussion of how valuable is that information, blah, blah, blah.
Indeed, the recent revision of the Office of Management and Budget circular that I have got cited here has actually taken that into account. In the first go-round with their guidance to agencies, they said, first decide what is sensitive and what is not sensitive, and then protect that stuff that is sensitive.
You can imagine what everybody did. They said, that is not sensitive, that is not sensitive, that is not sensitive, and therefore I really don't have anything I need to do. Government folks I'm afraid in general have a habit of saying, this is all public information, therefore it is not sensitive.
Well, that is patently untrue. If it is valuable enough for us to be spending taxpayer resources, if you will, taxpayer dollars to build these systems and operate them, there is some value in them, presumably. If there isn't, the issue is not a security issue, it is something else.
So anyway, to make a short story long, as my grandpa used to say, we want to try to provide some basic baseline standards or guidance.
Then the last thing is one that we have thrown on our list here, is to try to be technology neutral in the process, not to try to wire specific security requirements to any technology that maybe just exists today or is one kind of technology. That is the wrong way to go about this, because the basic technology we are trying to protect is changing on a regular basis, so we sure as heck don't want to be having our security mechanisms based on some given technology.
We have tried to make sure we have defined carefully what the scope of our work is and what we are trying to do, so that we are not trying to secure the entire world or all information that is handled electronically or otherwise.
Originally, if one reads the act, one might see that what we should be doing is just looking at those nine defined transactions and defining the security requirements for that. Well, even if we were doing that, we feel that there would be relatively little difference in security requirements for those given transactions. Indeed, the types of security standards or guidance that we helped to put forward would apply to any types of health care information. So we certainly have a broader scope than just looking at nine little transactions.
The act also says that it is important that there be consideration made with regard to the technical capability of various recordkeeping systems, the costs that are involved to implement any security standards or guidance that is recommended, other issues such as how long is it going to take to train people and personnel issues, all those things you can see on that list.
The primary rationale, I am assuming, and I don't have a legislative history of the act, but I am assuming that the concern there is the so-called small operator not be put out of business because some onerous security requirements are levied.
I think the approach that we are taking on this is not going to have that problem at all. What it does say, and I think it rightfully says, is that there should be a concern about having security mechanisms or protective mechanisms that are commensurate with the risks that you are facing.
Now, it ends up that in many cases, the determination of what needs to be protected and at least generally how much it needs to be protected is not a security issue. It is a policy issue up front. As I am going to point out with the next item in another slide, it is very important to distinguish between security and privacy. We are not addressing the privacy issues, we are not trying to establish what the privacy requirements might be for health care information. In fact, that to some extent has already been done, and there are folks that are directly involved in the policy and other related activities. There is a separate work group for that.
What security does is provide the mechanisms for implementing and enforcing whatever policy decisions have been made. I want to draw that distinction, and not get pulled into a privacy discussion, because only in a couple of areas is there a legitimate argument that certain security requirements have privacy implications. I'll get to that in a moment here.
Now, as I pointed out, we probably need to draw the distinction between privacy, which involves among other things a requirement of confidentiality in certain cases. But anyone who has read the privacy act or even partially understands the concepts and the discussions that have gone on for almost three decades now with respect to privacy, many aspects of privacy are making sure that information that is recorded about you for one reason or another, you have a certain amount of control over.
That is not just an issue of keeping it secret or keeping it confidential. You want to make sure it is correct, you want to have the ability to challenge it, all of those things. So those are all part of the privacy problem. It is a policy, it is a legal issue, it is not fundamentally a technical issue, although our technology has certainly affected how much we become concerned about privacy.
Confidentiality as I mentioned is one of the elements, and security is the set of mechanisms that allow us to insure or protect confidentiality, and these two other equally or normally equally important aspects of information and systems, integrity probably being the one that ought to be listed first. If we are not concerned about the integrity of data that we are maintaining or using in the decision making process, I've got to ask, what is it that we are concerned about.
That is not a privacy issue fundamental, except for your right to make sure yourself that data about you are correct.
Then another aspect of security that often gets addressed in other issues of reliability is making sure that a system that is supposed to provide some sort of a service or a process is available to do that. It can't be arbitrarily or accidentally disconnected.
So we look at the whole security picture as addressing all of those issues. We also -- again, in trying to define specific standards or guidance, it is important to not just say we need security. You really need to break it down into some way that allows you to look at more specific controls.
The traditional way, or the way that we have found to be most useful at least with respect to information technology is to make sure that there are mechanisms that enable us to identify the various players, the people, the users and the information or the systems to which they are gaining access, to have some sort of a mechanism that allows you to authenticate, in other words, prove that that user, who is probably off at the end of a wire someplace, really is who he or she claims to be, the authentication mechanism being the one that seems to be one of the major problems in large distributed networks.
You can't and often never see the individuals that are involved, and therefore, if you are going to be making business decisions or any other kind of access decisions based on, this is Joe Smith, you need some kind of authentication mechanism to verify that identity. And we have technology of course that enables us to do that reasonably well now if we choose to use it.
The third mechanism is one that allows us to in essence set rules, who should have access to what, and in some cases, what should have access to what. In other words, what system might have access to what other system and what functions. So that is a technical mechanism that is crucial in this whole process.
Then the specific mechanisms that allow you to enforce the access controls and enforce the identification. Then given that we often have to go back and determine what did happen for a lot of different reasons -- sometimes, when something goes wrong, you go back and try to reconstruct events or reconstruct information. Sometimes it is because something illicit went on, and you need to go back and find out what happened, for legal purposes or even law enforcement purposes. So there is an additional need for an audit mechanism or an audit trail recording mechanism, and then ways of handling that.
So those are the basic technical mechanisms that we tend to build security systems on.
Now, let me briefly tell you where our work group stands, in terms of what we have accomplished to date and where we are trying to take this whole thing. We have gone through a process of developing glossaries of key definitions, and we have made extensive use of work that has been done by others. In fact, wherever possible we attempt to identify other work first so that we are not trying to re-invent the wheel. We don't have time to re-invent the wheel, even if we had an inclination to do that.
We have established a website specifically for our working group, for the sharing of information, and then also for the bubbling up of information into the overall HIPAA website that is generally maintained.
Then probably the key thing that we have done is to try to make sure in this process of seeing what has been done, what people are doing and what standards people either are already using or want to use. We have spent a fair amount of time in outreach efforts, talking ASTM, AFEHCT, ANSE, et cetera; we've got several of those listed up there.
Also, we have had ASTM and CPRI come forward and suggest that some of the work that they have done over the last years and some recent work that they are doing could be part of a joint effort to try to identify and establish certain technical standards that could be used.
I think this is important from two standpoints, the fist one of avoiding re-inventing a wheel we don't have time to do, but more importantly, these are part of the voluntary standards community that comprises the folks who are out there recognizing the value of having standards that can be used for interoperability, for general cost effective operation. These are standards that folks have agreed to use.
So this is the way that certainly we at NIST have always attempted to use in trying to establish standards, rather than writing our own. I think the same thing applies in this activity.
I just saw a little note that I made on my copy of the slide. I want to back up one slide here just very briefly. I identified these five different mechanisms which are fundamentally technical mechanisms or primarily technical mechanisms, that comprise overall a security package. But it is critical to recognize that the overall security structure or framework has to include administrative procedures, in some cases physical controls, particularly in the area of access control. You often have physical control, even in the authentication mechanisms. Then there are a number of technical controls, so that was a point that didn't show up on the slide that I wanted to make sure that we discussed.
A couple of other things that we have done is in talking to the groups that I mentioned before, we have identified a few others that have activities going on, even if we haven't had the opportunity yet to spend time specifically with folks. There is a lot of material that is out there at this point, and it is very helpful.
Several of the organizations of the members of the working group have been involved in this area for some time. I am the deputy director of the computer security division at NIST, and we have for 30 years been issuing specific technical standards and management guidance in this area, so there is a lot of stuff that is available that we are going to be using.
What we are focusing on right now is what we have called, for want of a better term, a preliminary requirements analysis. That is basically, what is it that we need in that framework that I mentioned a couple of minutes ago.
The requirements analysis has as its underlying requirement something that allows interoperability when we are talking about electronic transactions. It is no good if we have one security mechanism or any other kind of information exchange mechanism that someone else can't use, and therefore just plug into, and interoperate, as we like to say in Dilbertland. So the interoperability issue is an important one.
Then in addition to that, we are concerned about consistency. In other words, one can apply or use lots of different types of technologies, but you are going to get inconsistent results and inconsistent levels of protection if you don't spend some time looking at the consistency issue.
The key activity right now is focusing on building what we can call a basic security model, in other words, something that allow us to identify the parts of what are existing in information technology systems that are handling any kind of information, but in particular health care information. We have built an initial matrix, what might be called a protection profile, but basically it is a matrix that identifies existing or available standards or guidance for protecting information.
We are generally looking at two classes or two states of information. For simplicity, we are calling it information when it is at risk, in other words, it is sitting on a disk someplace, it is sitting in backup material, and also perhaps sitting in hard copy form. That is essentially data at risk.
Then we also have the concern that most people identify with a computer security concern, data in motion, in other words, when it is being sent over networks or otherwise what we might call unprotected channels.
Out of this, we hope to develop those baseline standards that we were talking about, that I have mentioned several times. If you are going to use an identification mechanism in certain environments, it ought to be something stronger than reusable passwords, as an example. In other cases, that may still be an acceptable mechanism. But we don't want to get going on reusable passwords; I get on a soapbox quite often about that.
Anyway, we do recognize that there are a number of other working groups that are a part of the entire HIPAA effort. There is only a limited amount of opportunity to make sure that we aren't stepping on the toes or vice versa of one of our other working groups. So one of our ongoing efforts is to try to make sure that we aren't going off toward Joneses when everybody else is going the other way. So that is a constant challenge in this process.
A couple of the issues that we have to deal with. We don't want to be technology dependent or technology specific. We want to try to be neutral in that area. One of the ways you avoid that is by not getting too specific or too detailed in the requirements.
Now, of course the danger of that is, if you don't have things at a reasonable level of specificity, then people say, what is it I am really supposed to do? There is a certain mind set that says, tell me exactly what to do, I'll do that, and everybody will be happy.
Well, I can almost assure you that that isn't what is going to come out of this process. We all get paid reasonable salaries to analyze things and make decisions. It might be nice if someone could lay out a cookbook and that baseline set of standards that I was talking about would provide everything that one needs to do.
People that are looking for that are going to be disappointed, because there is no way in the world that we can do that without having everybody scream properly, tell me what needs to be done, don't tell me how to do it. I think if we are successful in trying to identify what needs to be done and avoiding saying do it exactly this way, then we will be quite happy and I think most other folks will be happy as well.
Ten as I also indicated earlier, because the act specifically cites some requirements or some analyses that says, don't make these things onerous, particularly for the small folks -- and I think if they are onerous for the small folks, they are also going to be onerous for the big ones as well, so that is one of the concerns that we have.
Then one of the other issues that we are still wrestling with is trying to keep separated and identify the technical requirements as opposed to the legal and other requirements in separating electronic signatures from digital signatures.
Just briefly, a digital signature of course is a very specific technical mechanism that is used to bind an originator of information to the information itself. You might think of it as a combination of checks to make sure the data are correct and also a wax seal that only I can put on that, and you can verify that it came from me.
So you get two things out of digital signatures: you get a verification of the integrity of the information itself, and you bind it to an originator. That is getting very simplistic in the process, but that is the essence of it.
The value of digital signatures and other types of encryption technology is, it means that we have an opportunity for a much higher level of security than we have in any kind of existing hard copy, manual process. As many of you know, one of the difficulties that individual states are having right now is to get their laws changed, so that things that require a pen and ink signature no longer will require that, as long as you have an adequate technical substitute for it. That is really what a digital signature is.
All of this has fundamentally nothing to do with scratching your signature on a little pad, so that that can be digitized and stored along with some information. One can use digital signatures to make sure that that was indeed the signature when it went in. But anyway, we are getting lost in some of the details there, but you can see some of the problems that we have.
I think that is about where I want to end this. I'm sure there are probably some questions. Well, maybe there aren't, maybe we have answered everything. But that is where we are going right now. We are on the same general timetable that everybody else is. In other words, it is way ahead of enough time to get everything done. One of the things that we have to face is the fact that both as the information technology that we are using is constantly changing and getting better and faster and cheaper; the security mechanisms that we are attaching to them are rapidly becoming more routinized, so that we will see them part and parcel of systems, and we won't even be thinking about them, I hope.
PARTICIPANT: By your discussion of digital signatures for electronic signatures, is the direction of thinking on the team that you would require digital signatures? And if so, are you looking to specify for what transactions, or in general?
DR. STEINAUER: The question, for those of you that are listening to this on real audio, -- since one of the things I learned sitting at my desk was, I couldn't hear any of the questions, I could only hear the answers, was, are we looking to specify what types of data or what types of transactions will actually require digital signatures.
I'm not sure what the answer to that is at this point. What we want to do at least initially is say, if a digital signature is required, here is a technical standard or a family of technical standards that will provide a digital signature that is trustable for whatever purposes.
That can be a very highly technically involved process. That is one of the areas where these kinds of technical standards can be very valuable. The next step then of course is to determine in which cases, what type of information is a digital signature needed.
I would argue that in the vast majority of cases, since what you are providing with a digital signature is simply a way of knowing that the information in a transaction is correct, and if that transaction is one that perhaps could be very fraud prone, then it is going to be in the best interest of either the government, if the government is paying for those transactions, or on the part of other payers who want to make sure that transactions have come in only through authorized sources, to actually apply a digital signature, or other mechanisms to make sure the data are correct.
You already do that. You have a lot of mechanisms, everything from -- back when we used to double punch every transaction in order to catch errors. That kind of thing is very expensive to do or might be very expensive to do, but if the types of efforts that it prevents justify it, then you do it.
Digital signatures are the same way. Now, one of the advantages was that this technology is getting rapidly easier and cheaper to use. The industry itself through a number of initiatives in the financial industry, among others, and in the network industry in general, are rapidly coming to closure or coming to agreement on basic standards for doing this. When all of that happens and comes together, all of a sudden that technology is going to be so simple and so cheap to use, you would rather do that than just send in a transaction without a digital signature on it.
DR. ZUBELDIA: I'm a little confused about the scope of the security work group.
DR. STEINAUER: You're not the only one. We have spent a lot of time on that. But go ahead.
DR. ZUBELDIA: You mentioned that this is for the defined transactions only.
DR. STEINAUER: For a reasonable amount of our initial discussion, we thought that was what the act said, and that we were to only look at those defined transactions. If you remember on that slide or noticed on that slide, I said defined transactions, comma, but dot, dot, dot. Our basic conclusion was some time ago that the kinds of security mechanisms that need to be applied are going to be needed, and they will apply for any type of transaction. So we are probably not going to spend much time at all looking and trying to analyze what is different from a security standpoint in those transactions.
DR. ZUBELDIA: From the list of entities that are involved in your group, I saw --
DR. STEINAUER: Entities as in organizations?
DR. ZUBELDIA: Organizations, yes. I didn't see X12 as one of the entities.
DR. STEINAUER: I did list ANSE and of course ANSE is the accrediting body for X12 and others.
DR. ZUBELDIA: X12 already has all the security mechanisms to secure the defied transactions. So it looks to me like what you are actually securing here is everything but the defined transactions, because the defined transactions already have a security mechanism through X12.
DR. STEINAUER: That is probably a fair statement, given that what we are concerned with is any kind of -- technically, we may be concerned beyond just the electronic exchange of information, but that is where we have something specific to say.
Basically, I think you're right. Those defined transactions are simply specific cases of more generalized EDI transactions.
DR. ZUBELDIA: One concern that I have is that you are taking into account the needs of the small provider and rural providers. I would like for you to take into account the needs of the large clearinghouses and switches, for instance, because if we have to do digital signatures and encryption with certificates on every transaction that we get, getting two and a half million transactions a day, there is not enough seconds in a day to do that. We have to move to Mars or something.
DR. STEINAUER: Yes, we have had some discussions, and that has been pointed out. I would like to think we would have recognized that anyway. That is why I went through a convoluted answer to the first question: are we going to require digital signatures on al types of transactions.
I don't think so at all. I don't think we have either the need nor probably even really the authority to say, you've got to sign everything. In most cases, the decision of what specific mechanisms are to be used will be determined by who the parties are that are exchanging the information.
Now, to the extent that in some cases, the government is one of those parties, it may be appropriate for the government to say, you send me transactions for ten million dollars, and I want the damn things digitally signed. But in general, signing all individual transactions is not an implicit requirement in any of this, as far as we see.
PARTICIPANT: Kepa, in line with your question, this is why we have added this interoperability. Our concern is that we are providing a broad array of solutions that can be chosen from by various players in the marketplace. The important thing though is that there be connectivity with these solutions.
So we are not trying to say -- we're not just catering to large or small or whatever. We are trying to come up with something that is going to meet everybody's needs, at the same time be appropriate for the level of protection.