Urology Coding Alert

Presented by Wayne J. Miller

The following supplement to Urology Coding Alert is the transcript of a teleconference presented by The Coding Institute. To obtain the slides for the conference, please log on to our Online Subscription System at http://codinginstitute.com/login and download the current issue, and the slides will be contained therein. If you're not sure how to use the Online Subscription System or need help downloading the issue, please contact our customer service department at 1-800-508-2582 or service@medville.com, and one of our representatives will be able to assist you.

The speaker for the teleconference, Wayne J. Miller is a founding partner of the Compliance Law Group, Los Angeles - a law firm focused on healthcare industry legal compliance. Wayne has practiced healthcare business and regulatory law throughout his 21-year career. Among its specialties, the firm has extensive expertise in HIPAA privacy and security rule documentation, training and compliance. He represents both individual and institutional clients, as well as healthcare-related businesses. Wayne is a frequent speaker for The Coding Institute national teleconferences on healthcare transactional and regulatory issues.

Thank you very much Mandy and good afternoon everyone. I appreciate the opportunity to talk to you about a rule that is going to be coming into effect in about a week and my comments today are, I think, going to be based in part on an assumption that many of you may still be working on getting ready for this deadline that is coming up.  Therefore we are going to try and focus on these rules and really think about what you should be doing right now, the portion of the rules you ought to be thinking about most significantly right now and then getting an overview of the portion of the rules that you might want to be thinking about over the long-term. 

I think if you have had some experience with HIPAA, this has been a long time coming, this is really the last of the troika of rules that you have to be worried about and you may have kind of a blas or you may even be groaning about, oh! yes, another HIPAA issue.  But I think that some of the events that have occurred in the last month or two in terms of disclosures from big companies - and I know they are not in healthcare - but all are dealing with really significant security breaches really bring home the need for you to consider these sets of rules to be very important and on the top of the desk of those who might be regulating and investigating it.  Basically the ChoicePoint and the LexisNexis and other big companies of the world who have had to disclose these terrible security breaches have really brought to regulators' attention that this is an important issue.  I have kind of rearranged my presentation because of these current events and I want to spend a couple of minutes almost looking at them as a case study because, in my mind, if you replaced a healthcare provider who would be subject to the HIPAA security rules, in place of a ChoicePoint or in place of LexisNexis, I would be concerned that they might have significant liability under the security rule for the breaches that occurred.  The reason being, these breaches are not, a sophisticated hacker who has come up with a unique way to get into information that would have been an unexpected event, but more a lack of, what I would say, diligence in dealing with the most basic security concerns among the concerns that you need to worried about under the security rule. 

So, I would say in large part, you need to really think about what the security rule says and you need to think that this might be the part of HIPAA where people might get tagged first, really beyond even privacy at this point because of this new attention to security problems with respect to electronic confidential information, so hopefully you will be paying close attention and consider this not just a groan or a blas, but something that you really need to be focused on.

The other point that I want to make, and I will be making it several times, is that this rule, unlike the privacy rule which I think of as more of a cookbook of things that you needed to do and you needed to follow that recipe pretty precisely, this side of the law is a little more, what I would call, amorphous.  It is akin, in my mind, to the rules or the manual that you see like by the JCAHO, the accreditation manual of giving you standards and guidance overall approaches, but it does not tell you that what you are doing specifically is okay or that if you use this system or that approach, you are going to be alright.  So, it really leaves it to you and to your advisors to best see how you are complying based on your level of organization, your time and your mind.  So, that is another issue to keep in mind.

We are doing to try to follow the slides pretty closely and I will try to give you reference to where I am in the slides, so this will hopefully help us in our presentation today.  On slide 2, I give a little background on myself.  I have done some speaking for the Coding Institute in the past on HIPAA issues.  As a healthcare lawyer for many years, I have gotten some interested involvement in HIPAA.  At this point in time, in terms of helping clients get ready for this part of the rule, it really has been incumbent to help them narrow down and compress some of these requirements and rather than saying, 'each requirement A, B and C I have to comply with,' it is more understanding what the goals are of this law. And then from that, looking at where you are most vulnerable and where you need to focus in terms of your written policies and procedures and things that you are actually going to implement.  So, in terms of helping clients, there are some concerns, and maybe even some frustration in saying "well, I don't know that I am a 100% compliant." I think that that is just the nature of this law and something you just have to accept that you are going to do essentially the best you can and be able to demonstrate that you did the best you could, not withstanding if an unexpected security breach did occur.

On slide 3, I give a little list of what we are going to try to go over today.  First, as I said, we are going to talk about couple of these cases that we have seen on the front pages about security breaches outside of healthcare, but they apply to you as well.  We will talk about the security rules, some of the jargon, legal part of this and where it fits in under HIPAA, get an idea of what the standards are that we are talking about.  Then we will also get into some of the myths that have come around this law, just like myths arose in privacy, then kind of really narrowing in on a list of, at least if you are a sort of a small or medium size provided, where we think your greatest vulnerabilities may be and where you ought to be focusing your documentation and your preparation efforts.  We will kind of talk about what you need to do in the short-term, you have got about a week and then in the long-term, thinking a little bit about what to do if the HIPAA police show up. I do not think you need to worry about them showing up on 04/20 and saying, 'what you are doing about security?'  But over the long-term, if there is a complaint and there is a review of your security procedures, how you might be prepared for that.  Right now, we do not have a lot of information about how that is going to go and so we are kind of making a prediction here because the powers that  be have not really told us how they are going do and they may not even be sure yet themselves because the law has not been fully implemented yet.  But we will try to give some thoughts about that. 

One thing I want to be able to say is again, and I just alluded to that, is this 4/20 is a deadline.  The deadline really is the first date which this law can be applied and can be enforced.  There is not any one particular event that has to be done by 4/20, although there are things that you ought to try to get done by then if you can.  But all that really represents at least the security is the idea that if you mess up, you can be judged under that law.  It is a little different in the privacy rule, where you had to have your notice of privacy practices or you have to do something by that date.  You do not have a specific event that you are going to do or have done, you just need to know that you are going to be subject to that law then.  If you have more things to do to get ready, you can take that time, but know that you are going to be subject to the law.

Under the next few slides, 4 and 5, I talk a bit about some of these recent cases and I find them interesting because I have really focussed on what it is that happened because that is really what you should be thinking about from a security standpoint.  Actually, the most recent event is not even on here and it is one I want to take a few minutes to talk about and that is LexisNexis.  But you have heard about ChoicePoint.  A lot of this has been really well covered in the press, I mean just about everything has been made public about what happened or at least a lot of information has been made public.  In LexisNexis, there were, as you may understand, several hundred thousand people affected, database information with private information of 2-300,000 people affected involving a data broker entity that they owned, similar to a ChoicePoint.  What is interesting is what were the events?  What was the attack, what was the vulnerability because that is the thing that you need to be thinking about.  In this case, there were three areas of vulnerability.  One was the fact that there were breaches involving password impact i.e., the passwords were so easy to figure out, names of people or whatever, that one could hack and use those passwords.  There were concerns about terminated staff and their access and apparently there was not enough effort to cut off the access of people who were no longer part of the company and yet they were able to continue to access and misuse information.  Then, there was also what we saw in ChoicePoint, where people were acting as essentially stooging for others.  They were pretending they were the appropriate account holder, whether they were a business or whatever, and got access by giving false information and then getting what would ordinarily be considered legitimate access to database information.  So, that is an example you have seen. 

Other examples, if you look at on the slide the UC system in University of California, there was recently a stolen laptop, just left out and someone picked it up.  It had a database of all kinds of information about students in the UC. So that is another example of a very basic kind of security breach. The last one is a physical access problem.  The LexisNexis and ChoicePoint are more technical, you might say, maybe physical, maybe administrative types of access problems that may have been preventable and are really very basic and not very sophisticated, and these are among the types of access concerns that the security rule is concerned about.  If you were LexisNexis and had these breaches occur, and the facts showed these kinds of errors, I think you might have very great possibility of liability under HIPAA.
 
The other part of these cases that you might want to take a lesson from is the time it took for them to find out the problem; some of these things kind of went on and maybe they might have gone undetected, but that is another process that HIPAA is concerned about - how quickly they responded and what they did.  Now, most of them have come clean and made disclosures, a lot of that is due to California and other laws that require that now.  But one might quibble with the time it took and with their systems that allowed this to continue for such a long time, if it took several weeks or whatever to find this problem.  So part of what you have to do is to be ready to mitigate and have procedures in place and hopefully maybe have, what we call, access controls to be able to hopefully find out these problems quickly at least to alert you, alarm you to a potential problem, so that you could get to it a little sooner than months or years later.  We will talk about more of these issues, but that is to give you a feel for why these recent cases, to me, show a fairly egregious lack of basic diligence in complying with some of the security requirements that you see in the security rule.

Over the next several slides, I kind of want to get into those rules and so we can take what we are hearing from these cases and see that it does apply to you.  Slide 6, just to give you the context, we are dealing with HIPAA, the Health Insurance Portability and Accountability Act of 1996, made 10 years ago approximately.  We have implemented privacy and the rules that specify how you do electronic healthcare transactions, the language, the code set and how you do transactions in that format and now we have the last part of this which is the security rules.  The key point of the security rule to remember is that it is different from the privacy rule in terms of what it applies to, i.e., it only applies to electronic PHI - individually identifiable health information and is not concerned really with how you deal with the paper.  I mean some of these standards are probably good about how you would handle paper, but a breach of security with respect to paper might be a privacy violation, but it would not necessarily be a security violation, so that is something to keep in mind.  In terms of your efforts, you are thinking about your computer, your media, all of the electronic digital things that you have that may contain protected health information. 

The basics of rules on slide 7 are shown there and I give you some citations if you want to look at it or if you have already referred to it.  It is good bedtime reading.  Similar to the privacy rule, in terms of who it applies to, will be a covered entity and if you are a healthcare provider or work for one, you are covered.  So, it is a direct obligation of you.  If you are a biller or a coder, you might have indirect responsibility as a business associate.  If you are none of the above, as we will talk about in a second, I still think that these standards might be applied to you if you have got PHI.  You need to try and at least follow the guidance, the standards that these rules set for you.  The other aspect of covered entity if you are a biller or coder and you are part of a healthcare-clearing house, you would have direct responsibility as a covered entity as well.
 
The rule is really broken down into different sets of safeguards and it is a good way to think about it, I sort of use the term APT to remind ourselves that this is a rule that is not just for techies, it is not just worried about what software you are using.  It actually goes much beyond that and actually the technical part is at most, a third of what the rule is concerned about, actually I think is less than a third.  It is concerned about administrative things you are doing, which in some respects are policies and procedures, but I would also call it really the 'people effort' that goes into security.  Do people follow rules that you have established, do people monitor other people who have access to computers and are they raising questions when somebody who does not seem to belong is accessing your computers? 

Then, there is also the physical aspect of security which is literally where do you have your computers, how would you ensure that computers are not accessed by those who should not get to them and how are they accessible to those who should have access, whether it is locks or whatever?  We will talk about some of that.  The key to kind of understand this rule is focusing on defenses against those who may be trying to attack you or whatever.  But the rule is also concerned about the flip side, if you will be offensive.  What are doing to ensure access, particularly if there is an emergency or there is a destruction or the lights go out, what are you doing to ensure that the people who need access can get access as well?  Really, when this rule was first developed, I think it was more concerned about that than it was about the defensive side.  I think the scales are changing, but the rule is concerned about both sides of the scale.  As well, you have got to be thinking about the fact that it has got to electronic PHI, and we have to be worried about and will talk about that in a second, but electronic PHI is a lot of things these days, and therefore getting your arms around that, understanding where it all is, is going to critical to you being able to say "I am in compliance with this rule."

On slide 8, I call in some respects in insecurity rule and that is because you get into what the standards that this rule has and how it is written and, as I said, it is kind of amorphous.  Purposefully, really, the rule is written just to approve any particular method, system, software or anything else.  It does not say, 'use Microsoft software,' although Microsoft wouldn't mind that, but it does not say that.  In fact, the reason for that is because this was not a document that was prepared at a single period of time and there is a recognition that security and security responses change over time.  I mean when you talk about Microsoft, they are adopting new security changes in their software almost monthly nowadays and making a lot of changes every time they seem to find a security problem.  So, the idea of the law is to say, 'we cannot predict how this is going to go, so we can only provide standards that we are concerned about.' 

The other thing about this rule is that it talks about scalability and a lot of people kind of believe that what that means is if you are small, you do not have to worry so much about it because you are small and you are not expected to do much.  I do not take that view, I think actually scalability is kind of scary because it really does not tell you how you are going to be judged.  A regulator may come to you and say, "Well I think as you are a small provider, you should have done more of these things" and you did not do them.  So, therefore, from my point of view, you did not do enough, I am going to judge you in my eyes, not in your eyes.  I would not give too much into that scalability thing. The key is for you to identify the issues you have and to the extent of your best ability and your budget to address what are going to be the most critical issues. 

The law has a series of what are called standards, sort of if you look at an outline, the ABC of the outline, and then a series of guidelines or specifications that are sort of the 123 if you think of an outline.  More detail or more description of what they mean by the overall standards.  Of those guidelines or specifications, there are 14 that are called required and 22 that are called 'addressable' and this is another area where people have said "well, if it is addressable, don't worry about it right now." 

Again, I do not quite agree with that and in fact the law itself does not quite agree.  What it says about addressability is if the requirement is reasonable, you ought to do it; if you cannot do it, essentially, you need to explain why you cannot or try to come up with an alternative.  So, I would not put much faith into what is required or addressable at this point and just kind of focus in on what your issues are and try to deal with those issues.   Realize what the guidance is, what the goals are of the law.  Enforcement is not by the Office Of Civil Rights, which is dealing with privacy, but actually by the Centers for Medicare and Medicaid Services.  I do think, however, the two agencies are going to work together, I believe, on security issues.  I mentioned on the slides as an example that if you are looking at the rule and you are worried about e-mail security, the rule does not say anything about what technology you should provide, but instead it is concerned about certain issues.  What it specifically is concerned about is the integrity of the information and access controls in terms of e-mail security, that is what it says.  These are the concerns it has, so you need to take that and say "well, how does that fit with the e-mail system that I have got?"  And we will talk a little more about some of the thoughts about e-mail systems in a few minutes.

On slide 9, just briefly, the rule will be I think a standard just the like the privacy rules become a standard, even for those who are not BAs or CEs or particularly subject to the law.  Even if you are in healthcare and you are in kind of a tangential position and you do not consider yourself directly covered by the law, I think you need to think about the standards that the law is imposing and some of those standards are at the bottom of this slide, slide 9.  We are talking about doing your own risk assessment of attack from a security standpoint, trying to identify those, trying to shore up vulnerabilities where you can and having policies and procedures in place regarding how you are going to mitigate and report and some of the things you might do if there is a breach and then having a process of reviewing what you are doing at least on an annual basis.  I think, if you are at least following those guidelines, no standards, you are moving down the road of compliance with respect to the security rule.

Slide 10 reminds you that you need to, as a part of your process of compliance, get your hands around as best you can where the electronic PHI is; it is no longer anymore in most offices just at desktop computers sitting at the doctor's desk or at a staff desk.  There is much more, whether it is a digital fax machine, your e-mail system, whether it is portable media, whether it is media outside of the office, laptops, so forth.  Also your networks, because a lot of folks are using wireless networks.  All of those are all E-PHI events, if PHI is being sent through those methods and therefore your security efforts need to consider all of those media and methods of transmission in terms of compliance.

Getting more into trying to comply, one of the things that I mentioned on slide 11 that is not doable at every office, but one thing to remember is that we are dealing with identifiable information.  One way to maybe lessen your burden here is if you can, to pull out of data that you have, the information that is identifiable.  And as a reminder you can look, there is a list of a number of different items that makes data as identifiable and that is under section 164.514 of the rule.  To the extent you can say, "well, the name, address and all that, my computer can separate that data and keep that in an area where I can identify and segregate it."  Your efforts may be more direct and maybe more effective.  As I said, not everybody can do that and it may be a process that you are not capable of doing with your system, but it is something to be looking for if you are looking at a new system and it may be helpful as well to think about 164.514E, which is the last item on the list of my slide 11, which talks about basically a limited data set - there are times when you can use data that has just a small amount of identifying information like name and social security number plus information.  Again, if you could segregate that out and keep that in a place or deal with the security of that separate from all the other information that is not identifiable, again, you may have a smaller job to be thinking about from a security standpoint because the law specifically is concerned about identifiable information, not de-identified information.

The next few slides, I would like to throw out the old 'I want to scare you' slides and I will just spend a couple of minutes reminding you about some liability standards of the client with privacy.  It is that if you have a problem with the HIPAA police, there are potential criminal and civil penalties and they can add up quite substantially if you are charged on a per-claim basis.  In other words, if this breach affects a number of patients, you could be charged for each of those patients, so the violation could start adding up quite a bit.  The method so far looks to be complaint driven and I think it will continue to be so, so I do not think you should expect to have somebody showing up on your doorstep saying, "I want to do an audit of your security" unless there has been a complaint.  I think the other concern, from a liability standpoint, is what the event was itself.  Again, if the breach was one of those LexisNexis events and you are not very far along in your security compliance process, I think the likelihood of bad result in terms of liability is going to be increased.  In other words, if the event is something that is really not likely to have been predicted like, again, a sophisticated hack or something like that, I think you might have more of a chance that this is going to be an educational experience.  But if it really relates to something that is simple and might have been preventable, I think you may be looking at greater liability concerns.

Slide 13 talks about HIPAA jail and basically meaning that if there was a criminal allegation or criminal finding that there is the potential of jail time and very severe criminal penalties.  The key, of course, is that you have got to show criminal intent, but sometimes intent can be inferred and to the extent we are dealing with a case like some of the ones we have seen in the paper where it really looks like there was a lack of diligence and a lack of caring and that something went on for a long period of time without it being detected or without anything being done.  Or if there is evidence that the people are trying to hide the ball and not disclose what happened and try to keep it all internal, these are going to be kinds of negligence, maybe grossly negligent facts that might lead to a criminal complaint, so you really have to think about that and try to make sure you are not the next ChoicePoint or LexisNexis when it comes to a security breach.

Slide 14 also just reminds you that there might be liability beyond HIPAA or interest beyond HIPAA if there is a problem.  There might be licensing issues, there might be, as I have mentioned, SOX which applies to public companies.  I do not think any of you represent public companies, but if you do, you have that potential concern.  And then you have potential cases involving the individuals who might have felt they were harmed and dealing with that, so bottom line is we do not want this path and we will avoid all this, but you should know that a security breach is probably on a bigger level than a privacy breach because it may impact so many more people.

Let us move on now, now that you are fully convinced that you need to fully comply, to really getting into the rule and some of things that we think you ought to be doing at this point, on slide 15.  The rule in a nutshell: I have already mentioned that you have a series of standards that are in three categories:  The administrative, physical and technical categories.  Then, you have a series of specifications, not necessarily under each of those standards.  Some standards have no specifications, some standards do.  Then, of course, those subcategories are further divided into those that are considered requirements and those that are addressable.  As I have said, I am pretty much ignoring that because of the requirement that the addressable specifications, in many cases, have to be adopted as well.  You want to be focused on the fact that the administrative guidelines, just on the basis of numbers, constitute at least 50% of all the standards and the administrative guidelines are really focused on policies and procedures.  There is a series of things that you are supposed to do to implement them, but one of the things that have to be in writing is policies and procedures.  So if it is telling you anything, it is telling you, you need to have your documentation in place and so that is the process that you did before with privacy.  Many of you may think, "I have done my policies and procedures for privacy, I don't need to worry about it."  I would beg to differ - you may want to supplement some of those policies and procedures, but I think you want to actually have a separate set for the security rules pretty much because it is separate distinct rule, someone coming in and looking at what you have is going to want to say, "where are you security P&Ps?"  Even if they are related to your privacy ones or maybe you already tried to address them, I think you ought to have a separate set so that you can say, "this is specific to electronic PHI security."  The other thing to address, of course, and we will talk about this again in a little while, is that because this is not purely a techie situation, this is not something you just say to your computer guy, "go, take care of this."  This really involves probably the person who is already your privacy officer and others who are involved in the non-techie side of security.  So therefore it may not make sense to have just your computer guy be in charge of the compliance with this rule because that is only a part of the requirement.

Over the next slide 16 through, I believe, 18, I have listed the overall safeguards under each of the different three categories:  the A, P and T.  I have tried to, almost purposely, to not get into all the detail of which is addressable and which is required because at this point in time, if you are still kind of early on in the process, you really need to delve into, narrow down what you need to be focused on.  What I am going to try to do on each of the slides is really talk about three or four of the bullet points regarding the areas where you ought to be focused at this point time.  As I said on the administrative safeguards, which is on slide 16, we are talking here about what you might have in your policies and procedures, the overview of management and really a lot of the things you should be doing right now to be in compliance.  It is really the paperwork and the people side of compliance and among these that are on this list that I think are critical are probably the first four right now.  And that is what is called security management which includes as part of its requirement the idea of risk assessment and implementation.  The second, third and fourth deal with issues of who is in charge, the chief security officer and access protocols that deal with the workforce and with the computer you are working with.  In my mind, from what I have seen elsewhere, if you are rapidly trying to comply, these are the areas that I think have the most concern and really are where you may be most vulnerable.  To comply with briefly security management, you need to be already involved in a risk assessment process.  A later slide gives you some ideas of how to do this, but thinking about how to document where your security vulnerabilities are and really it could be simple as a chart with four boxes or four columns in it.  The first column being the type of vulnerability or the issue, the second one being where it could come from, for example if the issue is password access problems - the attack could be from people who are not in your office or people who have been terminated or people who are not part of your staff.  The third category should be what this could affect, in terms of what systems could be affected by this, whether it is your desktop computer, whether it is an off-site computer and so forth.  The fourth column being what you are going to do about it; you have identified the vulnerability, but what are the steps you are going to take to make that vulnerability less?  And that set of information should, I think, be prioritized by what are the areas that you are going to focus your attention on. 

The SCO security officer is basically somebody who needs to be in charge of this process and, as I have already alluded to, I am not so sure it is just the computer person.  In fact, I would say, it should not be that person.  Maybe that person should be involved because they have the technical expertise to deal with some of the computer based security protection, but they are not necessarily able to deal with the other side of security which is the administrative controls and the physical controls.  They may have some impact, but they may not be able to handle all of that.  My feeling is that the privacy officer might be the right person to also be the security officer, with help from their technical person.
 
The other two bullets, the middle ones, the workforce access protocols and information access protocols, are again ones that I would consider to be really high on your priority list to deal with.  What are they talking about here?  Workforce access protocols are essentially the rules in terms of how your workforce is either entitled or not entitled to access confidential information or the private healthcare information; deciding who in your office, the doctors versus the administrative staff, who has or who does not have access to particular information.  It is similar to the concept of the minimally necessary rules, where you try to identify by role, maybe by position or by some other means, who should be looking at this and who should not, so your policies and procedures are basically a set of rules.  People in this position have access; people in these other positions should not be using these computers or should not have access to this particular information.  Your rules may also define who in the office or where in the office computers are going to be because that, in part, will impact access.  If you have a computer at the front desk, is that computer tied into your network that has all of the private patient information or are they only going to have certain local information that only that person can access and it will be less than the full PHI.  Rules in terms of, if you see someone who should not be accessing what should you do?  Ask questions or ask for their information or identity, and to go through what people should do when they suspect that someone is accessing information that they should not.
 
Similarly, on information access protocols, this gets into the aspect of trying to implement the minimally necessary rules under the privacy rules, i.e. you have access only to the information you need to do your job or to do the particular disclosure and this can be done possibly electronically, but it also can be done by people.  In other words, you have a rule that if you are a lower level staff person, you are not supposed to access all of the PHI, you may only have access to the first page of information that is on the computer, not to the rest.  So, you are essentially setting the rules on when it is appropriate to access and what is appropriate to access in terms of the information.  Again, you will see that some of the other rules kind of dovetail with this, because they may implement particular ways to secure or to ensure that you only access the information you need.  But, at this level, you are at least saying the rules, and the rules will be that only these people have access to this information - kind of similar to what you might have done on the privacy side.  So to the extent you can address those first four bullet points in your policies and procedures - risk assessment, dealing with who is in charge, dealing with the basic rules of access, whether it is the person or the information, that I think is going a long way in terms of what you need to be doing before 04/20, but that is not to say, ignore the rest of it.  What I am saying is maybe the other part you are going to be doing over a longer term. 

Of the other four items, contingency plan relates to what I was talking about before - the other side of security, which is just not the defensive side, but assuring access because one of the concerns of security is that if there was a power outage or some kind of disruption, there still is going to be a need to access PHI.  So the question is, what documentation do you have that has thought through issues of loss of power and so forth, and what employees are supposed to do in those cases, whether it is calling the security officer and arranging for a separate site to come up the speed or if it is moving from electronic to paper, making sure that you have a paper copy of things or relying on paper copies.  Whatever those procedures are in terms of getting ready for an event like that, is also important under these rules.  I think that if you do not have good contingency plans in place you need to address those but you may have a little more time to address them.  I certainly would urge you not just to do the first four and forget about the rest.

The next slide talks about the 'B' of the outline.  The safeguards that relate to physical safeguards and it is actually a shorter list.  Some of these I think are pretty intuitive in terms of facility access.  On the other hand, too, they get into issues of practicality.  How many different locks can you have?  If you have a fairly small office, you can only do so much in terms of segregating the PHI.  But in terms of trying to comply with these items - these safeguards or standards - my focus would be on a few of these. Particularly the workstation items, the middle ones.  Facility access:  I assume you have locks on your doors and you enforce those locks.  Issues of having an alarm system to help your overall facility security.  But really the key for you and for a standard office is going to be what you are doing about your workstation?  What they are concerned about here is use/access barriers and workstation physical security.  Now some of these ideas dovetail, but the critical thing here is again, that you ought to have policies and procedures about what things you do to keep the workstation out of the viewing and access by members of the public and those that do not have authority. Is it based on your having them in a separate office, your having them in a place where a person coming to it - just because of physical barriers - is going to be seen if they try to come and look at it.  They cannot just walk by it and look at it.  They have to make an effort to walk towards it. There are concerns of theft and making sure that you have procedures about keeping workstations where they are, whether it is using locks or other methods; trying to have physical restrictions on accessing the keyboard, accessing the screen and so forth.  Again, some of it is practicality.  The standards do not say, 'you have to have 20 locks on a computer.'  What it says is, 'we want you to have barriers to access that are physical.'  And so you have to think about practicality, as well as complying with the law.  I certainly would say that under the standard you ought to have - at a minimum - thought about where you have your computers and be able to describe how they are not readily accessible by the public.  And to the extent you can, having them secured in a way so that they cannot just be taken away easily or at least secure the hard drive that has all the PHI on it, and if possible, keeping that in a separate locked area.  As well, dealing with the considerations of physical security; that is, if you can, keep it in a separate room that cannot be accessed directly by the public.  Again, some of that is subject to your own restrictions and needs.  You may not have the capability to put things behind bulletproof glass, but you should be thinking about trying to minimize the ability of someone just to be able to walk in and see that computer and gain access to it.  The more barriers that you put up, the more likely you are going to be found in compliance with these physical safeguard rules.

The last rule or the last set of rules is the technical side.  Again, we have a series of standards that we are concerned about, but I would focus in on and really critically look at the middle three standards:  Computer audit control, which we will talk about in a second, and then this issue of authentication. Because as we saw in some of those cases, authentication is a real issue.  It is a real problem and even when you are big you can still get tagged by folks who pretend to be someone who can access the information.  So in terms of your policies and procedures and your efforts right now, I would be focusing on those two items.  Particularly in terms of authentication of information, the main concern I would have is if you are using the computer as electronic medical records and you are inputting information, is that you have the ability to determine that the information that is there - if someone accesses it - is accurate.  In other words, it has not been tampered with, has not been modified and so forth, and that any modifications are dealt with either by pending or adding information and whatever is added or pended can identified in terms of time and by who did it.  That way you have the ability to say, 'we have ways to ensure that this is valid information and has not been tempered with.  Authentication of user is something that is now seen in other instances, the importance of being able to have some kind of system in place to be able to tell that the person who is accessing is who they say they are.  In a small office that ought to be pretty easy in terms of saying, 'I know who should be accessing the information.'  It might not be so easy if you are using computers off-site or you are using PDAs off-site and you do not know who is gaining access to those resources.  So again, in thinking about this issue, are there things that you can do, whether you want to add it electronically through some kind of code that you assign to people or by some other methods that are available like E-Check or methods that are available online to authenticate the person. You might want to start moving down that road or try to at least describe what you are doing to try to ensure that the person who is accessing is the real person.  This is an area where you are not going to be perfect because as we have seen, breaches can occur, but I think in terms of the short term and the long term, whatever it is that you have done to try to ensure the authenticity of the person accessing the information at every level - whether it is in the office or outside the office - is going to be an important security issue that you need to be dealing with.

Moving on to slide #19-20, there are some myths that have come out of some of these rules and I want to talk about these rules a little further in the context of some of these myths.  The first one is this idea of e-mail and one of the requirements that you saw on the last slide - the technical requirements - is transmission security and that really relates to, when you are sending things over e-mail or over the internet, that there should be a security methods in place.  As I have said before, there are not any real rules about what method is going to work and what method is going to be acceptable.  There are no safe harbors.  When you look at the specifications for transmission security, the concerns are kind of generic and they talk about keeping the information valid - the idea I was talking about before that there is no tempering of the information - and assuring that only the people who are authorized have that access to the e-mails.  That is the standard that they give you and you are then left to try to make sense of that and figure out if you are doing the right thing with respect to e-mail security.  Do you have to get a new E-mail system?  Do you have to have a dedicated server or use a dedicated e-mail server that someone else may have that you may do through the internet?  The answer is that the law does not say you do.  You are not required to do that.  What you need to be concerned about is whether or not your method, your system meets whatever security standards there are and I have just described the two standards that they are concerned about.  What that is saying is that even if you are relying on let us say Microsoft Outlook and using an internet service provider for your emails, then that might be good enough if in fact you have done other things to make sure that there is security protection.  Among the things that I would say you need to be concerned about is making sure that you have updated your software with all the latest updates because a lot of those updates are security updates.
 
I would say as well that you need to be concerned that you have not just relied on the default settings.  Often the screens that e-mails have in terms of security screens, in terms of how much encryption is used, who has access and other rules and screens that can be applied through the software itself.  Make sure that you have thought through those security screens and are not just relying on the default because the default may be a very low-level security protection.  I would say that at minimum you need to do that.  At maximum, you may want to have someone review your e-mail system in terms of vulnerability and whether or not there are other things that you should be thinking about.  For example, if you are doing a lot of online e-mail visits where you are getting a lot of PHI over the e-mail because of visits with patients, you may need to have what is considered a more secure type of e-mail setup, whether you are using a particular system or have your own e-mail server. 

Again, I am not saying that the law requires that but you may want to feel that you are more protected or that you have a higher level of security because of the greater sensitivity of that PHI.  Not to say that other PHIs are less important, but the likelihood of getting very personal information increases if you are doing online visits.  Another thought that you will hear a lot about is that you should never send PHI electronically.  I just think that that is not possible anymore.  All of you, I am sure, send PHI electronically and while that is a very conservative way, I suppose, to meet the law and it means that you keep all your PHI in house, it is just not the way of the world.  So, therefore, again knowing that things are not going to be perfect, you have to try to shore up as best you can your transmission security.  Again, whether it is upgrading software, whether it is limiting what type of information you send over the internet, or whether it is using a dedicated server.  Those are the things that you need to be thinking about.  As I said before, this is not just a technical issue and you have got a lot of nontechnical concerns, particularly administrative and physical concerns too.

A few more minutes on slide #20.  As I have already said, I do not think that addressable requirements are optional.  You need to do them.  Again, I think you ought to be thinking more in terms of vulnerabilities and what you are doing to address those vulnerabilities rather than saying, 'I am going to do requirement X and not requirement Y.'  It is more in terms of where you think the greatest risks are and where your focus ought to be in.  I have already talked about that.  Software updates are important, as I have already said for e-mails, but it is not the only answer.  You will also have to look at what your people are doing.  You have to look at how you physically protect information because those are other ways in which you can prevent people from inappropriately accessing information.  If your people are vigilant, if your hardware/software is locked up in a place where people do not know about it or cannot get access to it, that is going to give you as much or more protection than what you could do to your software.  You really have to be thinking about all three categories of A, P and T. 

Now on slide #21, as promised, I have listed here the specific areas where I think a typical small or medium office may have the greatest vulnerabilities, and you may want to pick and choose from this list or use the entire list to really develop your own risk assessment and focus.  Of the ones that are on here, we are not going to have time to talk about all of them.  But if you are going to look at time and say well, do some of these now, focus on some of these now and some of the rest over the next several months, I would be concerned mostly about the access - the one that talks about access.  Those are really your first line of defense in terms of  security and as we saw in those other cases, it was the lack of diligence as to access which led to their downfall from a security standpoint.  So if you look at this list, the physical access controls, the minimally necessary access issue and remote access are all areas of focus with respect to your policies and procedures and to your security compliance efforts.  I am not saying that the rest of them are not important.  They are important as well and among those others, probably the e-mail and network security are up there too because transmitted information  is vulnerable to attack.

So getting further into the access issues on slide #22, it is clear that that is the key issue under all of these sets of standards.  You have issues of access protocols under the administrative standards; under the physical standards you have issues of appropriate access to the computer physically.  In the third category, you have other access categories in terms of how you implement access controls in your software.  In terms of your assessment as to access, we talk about some of those on slide 22, and some of them are intuitive and some of them may not be.  Certainly, I think that you ought to be able to say in your policies and procedures and in your implementation that you have located computers in a way so that people cannot get at them who do not belong there - people who should not access them.  But that assessment should also look at those who have computers off-site (hopefully not in their car, at their home).  What exactly are they doing in terms of physical access and in terms of making sure that only the right people have access to the laptop or PDA?  Likewise, in terms of the technical side, clearly password controls are your very first line of defense and do you enforce, from an administrative standpoint,  changes in password  So the policy and procedure as to the administrative side should require people to change the passwords every month or every couple of months.  As well, there should be education about how the password is set.  It should not be your dog's name or whatever.  That is so simple and so basic and yet we even see in these big company cases where they fail in that regard.  People just over time are not as diligent.  I think part of your job is to make sure that there is diligence as to passwords.  The other thing that you need to think as to passwords is whether you need multiple levels of passwords and maybe that is the way to meet the minimal necessary standard.  If somebody has a password to level I of information that will get them the first page of the information.  If they have level II password code, like the doctor, they can get more information.  That is the way to technically address access control as well as the minimally necessary issue.  The other items on this list are very important in terms of vulnerability of the network and internet access for making sure that, for example, if you are in a shared office and are using a wireless network that you have looked at the password controls and at the ability of others to hack into your system through the network.  Often people again rely on just the default security systems that are there in a wireless network and that is very low security.  So you want to make sure that you are not getting breached through that method as well. 

On slide #23, we go beyond just doing the policy and procedures to what you ought to be really focused on in improving access controls.  Among them are the things that we have already talked about.  The physical things that we can do as well as the rule-based things that you can do.  Some of this is just a matter of rules saying that if you are a nurse or doctor, you can access this and if you are not, then you cannot.  But it can also be just the physical things that you do that only the doctor has access to the database in his office and others do not. 

Lurking access problems under slide #24 are things that may not be so obvious.  A couple of them that I want to mention include the first one.  The rule compliance issues.  You know people are interested when it comes to computers.  Sometimes people want to get around the security that is there so that they are not bothered by it.  For example, you might have a vulnerability where someone can start using a program like Word and then get into another program that has PHI in it without having to go through your security protection.  That is a breach of access vulnerability that someone else could take advantage of.  So part of what you need to be thinking about in terms of access is whether or not people are really complying with the access requirement and are not finding a way around it.  Part of that is going to be talking to people in your office and maybe even monitoring folks in your office. 

This next area is more long-term, but it is very important under the security rule and there are examples where this failure hurt those big companies that we have been talking about and that is the last two items on slide #24.  When information is not as active anymore and your are either storing it or you are destroying or backing it up or so forth, whatever systems you have there need to be consistent, and whether it is physical security issues or access issues, you need to be applying those rules and those standards to that information.  You cannot just forget about it and put it in a drawer.  If you have got a disc or another media that you want to re-use and it has PHI on it, what are your destruction methods?  It is not just enough to delete.  As you may know, you need to think about things like bleaching it or even destroying the media itself completely.  If you do not have really good procedures in place on that then that ought to be part of your long-term plan in terms of developing good policies and procedures and processes for that.

Under slides #25 and #26, we are talking a bit about trying to think about the 'gate' and where the first stages of security breaches could occur and really focusing your compliance efforts and your policies and procedures on those, in addition to what I have talked about.  You should be thinking about accidents waiting to happen, whether it is because you have not updated your firewalls or you have not checked into what people are doing on their passwords for a while or you that you allow a lot of non-compliance with security protections.  These are the things that you ought to be going back to and focusing on because this is really the first level of attack when there is a problem.  Certainly, you ought to be eliminating - if you can - easier issues.  One of the things that have hurt people in the past are broadcast faxes to the wrong people with PHI attached and just inadvertently sending out a bunch of PHI to the wrong place.  Do you have methods in place, whether it is rules of people having to check three times before they send an attachment, or something in the software itself that says, 'are you sure before you send an attachment' to make a person take a minute and think before they send or even prohibit it.  Prohibition on people being able to send certain PHI.  To the extent you can impose those requirements that is an area where you can avoid problems right away.  Similarly you may want to think about, if you are getting bigger and if you have more resources, what we call intrusion devices.  This is the ability to monitor who is accessing the information at let us say an administrative level and being able to say if somebody is accessing it who has not used the right code or seems to be accessing information that they are not supposed to access because of the information that you have, that will trigger an alarm that may stop that computer from working or whatever.  That is another area where you can provide more protection for yourself and maybe more of a long-term effort, but one which I think the security rule is looking to.  Do you have ways to monitor use so that if somehow somebody breaches the system you can find them and you can identify them within a fairly short period and do something about it.?  As I have said before, that was the failure in some of the cases we have seen and I think that you are going to see the regulators wanting to know that you have some kind of system in place or you are working on getting it or you have ordered something that does this kind of audit control at the computer level to see who is using this computer and monitor the use.

On slide #26 and over the next couple of slides, I am really focusing on and advising you about what you should be doing now.  Slide #26 states that what you should be doing now is some paperwork and I have listed there policies and procedures specifically, the categories that you should really make sure you have something on.  As I said, this is going to be a separate set of policies than the privacy rules.  Among those that you see, as I mentioned before, is what do you do for information that is not used all that much?  Also, issues of how you authorize people to use the computers.  What are the rules that apply to people?  What are the people rules?  Any kind of restrictions that you have or security that you have not placed for E-mails - what have you done about that security, whether it is updating software, whether it is setting up your own server or whatever it is that you have done.  Also, identifying the chief security officer and what their duties and roles are.  These are the things that I think your paperwork should deal with right away in terms of policies and procedures.  These are the minimum things that you should have. 

#27 also talks about what you do and what have you thought about if there is a breach.  Again, this might be a higher level or a more serious breach affecting a number of patients if it happens because databases could be accessed with a lot of different names.  So this might be similar to what you have done for privacy.  You ought to identify a team, how quickly they are going to respond and who is going to take responsibility for response are some of the things that you might do to deal with mitigating the problem.  These all should be related in a policy and procedure and you should be ready to implement it if needed. 

Slide #28 again reminds you about the person being in-charge and what their roles should be.  They need to be someone in management, but maybe also having some IT background or IT help and they need to understand - kind of like the privacy officer - where electronic PHI is and be able to have the authority to do something.  They may be the person who will investigate a problem or hire problem to investigate, and make decisions about mitigating a problem or how to respond if a problem is identified.  Also critical right now is this assessment.  We have talked already that when you are doing your assessment it may be as simple as these four categories that I have identified in #29 - just a chart and prioritizing the items on that chart and looking specifically at the things I was already talking about, particularly access controls and issues of e-mail, physical controls and rules that you are imposing on your staff.  These are the things that you ought to be focusing on, listing and prioritizing in terms of whatever you are going to do, what you are going to focus on and what you are going to do to shore up vulnerability.  The other side of the equation, assessment of contingency plans is also an important activity and I would say that that is something you need to do in the next few months.  You do not necessarily have to have it all in place by next week if you do not have the time to do it, but it is clearly important because it is the other side - the other side of the scale - that comprises security and is as important under the law than just the defensive activities that you are engaged in.

Slide #30 reminds you of what to do now and what to do later.  The first three items I feel are what you need to do now, which is to do this evaluation, maybe do some training of people reminding them what the rules are, like about passwords and about when they see somebody that does not belong on the computer, to identify who has access to computers or what information they have access to.  The last three I think are on a longer-term scale: scheduling, the fixing up of things that we did not identify as real critical, updating your contingency plans and reviewing what you are doing.  That is a longer-term exercise.

Slide #31 reminds you of the activities involving with mitigation.  What you ought to be covering in your policies and procedures and what you ought to be prepared to do if you have to mitigate a security breach.  You need to try to identify who is going to be involved, who the team is, and what the range of possible actions may be.  You cannot predict all of them, but you might say there will probably be some disclosure, there will probably be some disclosure to patients and maybe disclosure to governmental entities.  There may be some consideration of remedies to patients.  There should be some attempt to get the information back if we can or try to undo what was done if we can.  And then talking about who you might include whether it is a lawyer or so forth in this process, and then what your steps are going to be.  You are going to investigate, do a report, and then maybe make a disclosure.

In the last couple of slides or at least slide #32, I wanted to just talk a minute about what if the security police - the HIPAA police - show up.  There is a complaint that somehow somebody got access to information that they should not have gotten access to or there was some kind of disclosure that should not have occurred.  What can you except?  What should you be prepared for?  So far, the problem is that we do not really have any standards.  We do not know what the government is going to hold you up to.  They have not really said and there is nothing in the law that tells us.  What I do think they are going to do is to say, "we are going to look at how well you were prepared for this and whether or not what happened was something you could have been prepared for.  Were you prepared for it and it happened anyway - not withstanding everything you did?" 

What you should be prepared for is to show them essentially your policies and procedure and your process.  That is what I think they are going to look at first.  It may be more educational in nature, depending on the egregiousness of the problem, but you should be prepared.  That is why I think you need to prepare your policies and procedures and think about some of these critical issues like access and so forth because you want to be able to explain what you did and how you were prepared for the issue.  I think for now, until we get more standards and more information, that is the way you should be prepared.  That is what you think is going to happen if someone is going to come to your door.  They are going to say, "well how well prepared were you?  Was this something that was avoidable or was it something that was going to happen no matter what your diligence was?"  You ought to be able to defend that position that yes I was prepared and I did it.  I handled this in a very diligent way.  Part of your success is also going to be how you handle it.  When you decide what your mitigation is going to be, whether it is going to the government and making the disclosure yourself or some other method, that will also be reviewed and considered.

Finally, I want to give a few minutes at least for some questions.  My last slide is sort of a wrap-up of some thoughts to pull together from the things that we have been discussing already.  First of all, pre-deadline: what should you be doing?  I think you should finish your assessment, really focus your assessment, if you have not done much of it at or at all, mainly on access controls and perhaps on transmission controls.  Whether it is your E-mail, whether it is access by wireless and trying to see what you can do right now to shore up protection and vulnerability.  Also, I think you need to have prioritizing of everything - all of your potential risks - and scheduling when you are going to the get the rest of it hopefully in a short period of time.  I think as well you need to have your paperwork in place.  You need to have those policies and procedures we have talked about and also working on staff awareness because that is a critical part of compliance with this rule - the administrative part of this rule.  I think, again, when you are talking about all the different places that electronic PHI is, you can only right now kind of focus on where you might be most vulnerable.  I have given you some clues as to where the culprits might be, where the issues might be and I think you also should be aware that if there is a problem, you may be seeing more than one agency involved.  So you want to be prepared when they come in to be able to show that you have done a diligent job in trying to defend against access problems or security problems, as well as, being aware of the fact that you want to keep information accessible to those who need it, like the doctor and so forth.  Show that you have done your diligent job in maintaining security and that if anything bad happened, it is not because you have not been diligent.  So let me stop there and turn it over to Mandy and see if there are any questions.

Thank you Mr. Miller.  Ladies and Gentlemen, I would like to remind you that this portion of the teleconference is also being recorded.  If you have a question at this time, please press star (*) one (1) on your phone now and you will be placed in a queue in the order received.  If your question has been answered or you wish to remove yourself from the queue, please press pound (#).  Please limit yourself to one question at a time so that everyone may have a chance to participate.  If you have another question, you may reenter the queue by pressing star (*) one (1) key.

Q & A Session:

Question:  Hi I noticed that you mentioned that the security rule is set forth in 45 CFR 164.306, etc.  Is there a section where the bulk of the language of the security rule is set forth?  Can you identify that?

Answer:  If you go into the beginning of that section.  It lays out sort of a summary of the different, like the TAP.  There really is not any one place there where it is in the way I have described it.  I have some material that kind of gives you a chart that will list the standards and the specifications.  That might be helpful for you.  If you are interested, you can send your e-mail address and I can provide that to you.  The law itself, you really have to kind of go through it section by section to pull it out, but at the beginning of that site I gave you there is at least a short summary of the overall standards.  But you probably want to have something that is more like a list and as I said if you need something like that I would be happy to get that to you.

Comment: Thank you very much.

Question:   I am going to read through some questions that were sent in by e-mail.  The first one states that we did a GAP analysis and risk assessment prior to implementation of the Privacy Rule.  Is that enough or do we need to do those activities again?

Answer: That is something I talked about briefly in the presentation.  There are things in your privacy assessment and policies and procedures that touch on security and may touch on some of these issues.  For example, like the minimum necessary rules I alluded to.  But I think that you really need to have a separate set of review and consideration as to the security issues because it is specific to electronic PHI, which is not the same limitation as to the privacy rules.  There are particular unique issues like access controls and so forth that you see under the security rules that you do not necessarily see under privacy.  The bottom line is "yes" that you do need to do a separate assessment and really a separate set of policies and procedures.

Question:  Okay.  The next question says, " our office may need to terminate an employee who has regular access to all of the electronic PHI.  What steps should be followed to reduce the potential security breach?"

Answer:  That is something we have alluded to.  One of the problems here in one of the cases we have seen is that people who are terminated are still having access to electronic private information or electronic confidential information.  That is a real issue that I think can be addressed fairly easily and one in which I do not think that you should have a breach caused by that.  If you have procedures when you terminate or an employee resigns, part of that process should be to look at what access they have to electronic PHI and cutting that off, whether it is changing passwords or cutting off the ability of that person's password to access both onsite and offsite; making sure that the people are monitoring so that they see that that person is not trying to access PHI or trying to get on the computer having access controls that might give you an alarm when that persons tries to access because they are no longer authorized.  One of the critical things is to get that done quickly because part of the problem in some of these cases we have seen is that either it is not done or it is done very slowly, and in that period of time a breach can happen.  I think the answer to that question is that the steps should include those additional issues like cutting off access to E-PHI in addition to whatever else they may have.  They may have an interview with that person to find out what PHI they have.  I think, as well, one other thing that might be helpful is to make sure that you have a current inventory so that if people who are being terminated or are resigning have access to information or PDAs or whatever media offsite, that you have handle on what that is and what PHI, if any is on that, making sure that you have procedures to either get that information back; get the hardware back and making sure that nothing is copied or accessed by the person who is being terminated.

Question:  Okay and the final question that I have says, "We use Outlook 2003 and a commercial ISP for our e-mail.  Do we need to change that under the security rule?"

Answer:  We talked a bit about E-mails and again the basic rule is or the basic provisions in the rule are that there is not any one system that is okay or not okay.  As I said, what you get are some guidelines stating what we are concerned about in terms of transmission are a few things, specifically that the integrity of the information, that it is not impacted when it is sent from point A to B and so that the person at point B is getting the information that was sent.  Two, issues of access controls.  Thinking about that and knowing that those are the standards, then you turn around and look at what you have and whether or not what you have will meet those standards.  Among the things that I would look at is how do you update the software for your E-mail systems?  Is you e-mail system using some level of encryption?  Is that encryption appropriate?  What have you done to ensure integrity of the information?  Is there something that you have done?  Is there something more that you could do?  I would say at a minimum you do not want to rely on the default security rules or filters that are available in your software.  You want to look at what is available, look at the security rules of your software and make sure that you are using the highest level that is most practical and most effective for you.  I think that that could be the first thing that a regulator is going to look at. 

Then secondly, I think you have to think about what is appropriate to send over E-mail.  If you are doing online E-mail visits, you have to think about the fact that you are going to have a lot of PHI there.  Are there other situations where you do not have to send PHI over the internet or do you want to have some restrictions on who can send PHI over the internet so making sure that the access issue is also addressed.  As we see it is not the system that is important, it is how the system works.

Okay.  This is the conclusion of "Top HIPAA Security Pitfalls and Secrets to Avoiding Them" national teleconference.  We hope that you enjoyed this session.  Please complete your teleconference evaluation form and return it to The Coding Institute at the address listed on the form.  Mr. Miller, The Coding Institute and I would like to thank you for your attendance.  To end this call, simply hang up your phone.

Once again, please refer to the pdf version to view slides.