Call Today 1-877-740-5028
Online Tech and guest speaker Attorney Brian Balow of Dickinson Wright discuss how to handle HIPAA security and privacy concerns with using patient portals. This informative webinar is ideal for covered entities and business associates in the healthcare industry, including HIPAA hosting providers and those that use their services.
Title: Security and Privacy Concerns with Patient Portals
Description: The HIPAA Privacy Rule grants individuals the right of access to inspect and obtain a copy of protected health information (PHI) about the individual. Medicare and Medicaid’s Stage 2 Meaningful Use requirements include the obligation of eligible professionals and hospitals to provide patients the ability to view online, download, and transmit their health information, and of eligible professionals to use secure electronic messaging to communicate with patients on relevant health information. And outside of this, patients as consumers are demanding better and quicker access to their health information.
While electronic portals are lauded for their ability to afford patients easy and fast access to their health records, the creation and use of these portals raise legal and regulatory concerns that fall outside of the typical covered entity/business associate/privacy and data security construct under HIPAA. Please join us for an informative discussion of these issues, and some recommendations on how to minimize risk while successfully deploying an electronic patient portal.
April: Hi, everyone. Thanks so much for joining us again today. We’re back for another Tuesday at Two webinar. This is April Sage from Online Tech. Please join me in welcoming back Brian Balow. Brian is a member at Dickinson Wright and an attorney who specializes in Healthcare IT Law among other aspects of law. He’s rejoining us today to talk about the security and privacy concerns that are unique to patient portals. Many providers and their business associates are striving to meet the new meaningful use stage two requirements that they engage their patients and, at the same time, fulfill their responsibilities to protect the sensitive health information. To help us navigate along that complex path, Brian, welcome. Thanks for joining us again today.
Brian: Thank you, April. I’m glad to be here again. I’m think this is my 3rd opportunity to work with Online Tech and I greatly appreciate it and the folks that attend. It’s a good day here in Southeast Michigan because the sun is shining and I think that’s the first time in about the last 60 days that’s been the case.
April: I can vouch for that.
Brian: Right. I’m pleased to be here and, as April indicated, we’re going to take a narrower view of the overall privacy and data security issues that surround health information. With that, April is going to drive the slides for me today. If you could go to that first slide. Thank you.
So the overview of what I want to cover today, first of all, are definitions. As many of you know, there are a number of definitions out there, various regulations and laws and, otherwise, that speak to electronic health records, electronic medical records, Protected Health Information, so on and so forth.
There are two definitions that I thought we would focus on today. The first is patient portals and the second is personal health records. I think you’ll see shortly why I wanted to select those two to cover. The second general area I want to cover are the drivers for the adoption and use of patient portals and April has already touched on one of the key drivers, the meaningful use stage two requirements. There are obviously others as well. We will touch on those.
And then, the bulk of what we’ll talk about today are identifying and, hopefully, managing the risks that are associated with establishing and operating a patient portal.
Brian: The definitions for patient portal. A patient portal is a secure online website that gives patients convenient 24-hour access to personal health information from anywhere with an internet connection. That is the definition that you will find at that link that I’ve included there from the healthIT.gov website.
There are some key aspects to that definition. Number one is secure. I think it’s interesting that they include secure in the definition that is obviously a clear drive director for all of us that they do expect these to be secure portals. 24-hour access, convenience, and then they speak to personal health information. Again, I find it a little bit curious and maybe a little bit … Distressing might be too hard of a word but, personal health information, it’s not really a defined term in the pertinent rules and regulations. As you know, HIPAA really focuses on Protected Health Information but, in any case, maybe they intend to and they’re defining patient portal as to a broad map. A little bit beyond just the Protected Health Information.
That’s the definition that I’m going to use related on for patient portal. Excuse me. And then, the second is personal health record. That is actually a fine term in that definition. It actually comes from the Federal Trade Commission Act. It is defined as an electronic record of PHR or Identifiable Health Information which is really analogous to Protected Health Information under HIPAA. Out of individual, they can be drawn from multiple sources and that is managed, shared and controlled by or primarily for the individual.
I think the key there is that the last part of that managed, shared and controlled by or primarily for the individual. Again, it’s in contrast to what we deal with under HIPAA and Protected Health Information. HIPAA is really aimed at making sure that Protected Health Information is secured and is handled in a way that prevents its unauthorized disclosure to protect the individuals.
It’s not aimed at communicating Protected Health Information to the patient. It’s aimed at how that information gets communicated among providers, health plans, in other corporate entities and business associates. The personal health record definition does go more to the record that is shared, controlled by or primarily for the individual.
Brian: What are the drivers for adoption and use at the healthcare market and consumer demand? I think that is clearly the case. We live in a world today where people want information. I think people are more and more involved in their own medical care and medical decisions. A large part of that is for us to have ready access to our health information. I think the market itself, consumer demand is driving this.
The second is improved quality of care. I’m not going to say to you any empirical studies but I think we all know that when we look at the various laws and regulations that are pointing toward the adoption of patient portals, they speak to improved quality of care as one of the elements that should be prior to that. A large part of this is the whole concept of coordinating care. The coordination of the care is entirely between the various providers, labs and others who are involved in the treatment of the patient. It involves the patient’s input as well. There’s a view that adoption of patient portals will help to improve quality of care.
The next one is work flow efficiencies. I believe this is more targeted again to the provider and treatment side not necessarily directed to the patient’s involvement but extent to which there are portals that can allow such things as scheduling, delivery or access of lab results to the patients in some cases, delivery of negative test results, those kinds of things negative in the positive sense that there’s no issue to the patient can create workflow efficiencies. If the doctor or someone from the doctor’s office doesn’t have to get on the phone and make phone calls to the patients and patients are advised and know that they can reach in and grab the information themselves, that can create workflow efficiencies.
The next driver is technology. With cell phones, I think I heard this morning, there are more cell phones in the United States than there are residents or citizens of the United States which is a remarkable statistic. With technology and with all of the mobile medical applications that are coming online right now and the FDA taking a hard look at that, that’s not going to go away. With the mobile applications out there, that’s another driver for covered entities to get involved in the patient portal business.
And then, the last, April identified this at the outset, the meaningful use of stage two requirement which I’ll speak to you in a little more detail in a couple of slides. Those are some of the general drivers for the adoption and use of patient portals. I’m sure that’s not an exhaustive list but I think it’s a pretty good list of indicative ones.
Brian: Patient portals, generally, there’s a fundamental underlying premise that’s critical. That premise is not just a premise. It’s a legal reality that patients are entitled to copies of their Protected Health Information. That’s under HIPAA. HIPAA imposes strict penalties on covered entities/business associates for non-compliance with its obligations. If I want to go to my doctor, my primary care physician and say, “Dr. so and so, I want a copy of my medical record.” He has to give me a copy of my medical record. I’m not going to go into details as to how that has to be delivered but I can assure that it’s in the regulations specifically outlining in what form that is be delivered to me and what timeframe, so on and so forth. I am entitled to that if I want.
There are significant penalties for not complying with this and many of you on this webinar are likely aware of Cignet matter. I think it came out of Maryland. They violated 41 patient’s rights by denying them access to their medical records. Now, I don’t why they would do that, what the basis was for them refusing to do it whether it was just negligence or there was some other reason why they felt they did not need to turn those records over but they needed determination not to. There were several private actions brought. And then, it got to the Office of Civil Rights, add it up, fining them 1.3 million dollars. That 1.3 million dollars was for the failure to turn over the medical records. There was an additional three million dollars fine assessed because Cignet refused to cooperate with OCR’s investigation.
This is a real issue and, again, the basic underlying premise here is that patients are entitled to copies of their Protected Health Information, their medical records, etc.
Number two is the implementation of a patient portal could ease the compliance with this obligation. I think that’s maybe self-evident that if you add an operating, functioning patient portal that included through that portal access to the patient’s PHI, that might be one way to comply with the HIPAA requirement and release some of the burden that might be imposed if you did not have that and you’re just receiving and responding to individual requests for an information. The trade-off is increased security burden surrounding the portal.
Anytime you increase access, you increase security issues. That’s just the nature of the internet. We all know that as well. If you’re operating a fairly compliant system where you don’t have a patient portal right now and you’ve got your ducks in terms of how you’re sharing PHI from covered entity to covered entity or covered entity to business associates, if you open up another means of access through a patient portal, that will increase the security burdens and potentially the risk associated with that.
As a result of that, some portals are used for very limited purposes. One thing I should back up and say is, as of now, the patient portals could be tailored really any way that the covered entity or provider wants to do it. You can use it for very limited purposes with the patients or you can use it for very broad purposes with the patients but, again, doing so, understanding the risks in terms of how much information you allow to be accessed.
Again, because of this, right now, some portals are used for limited purposes like appointment scheduling, again, I mentioned negative test results. If I had blood test wrong and I wanted to go see what the results were, the physician’s office might post those as long as they were negative results. And then, maybe medications listings, that kind of thing. Again, point B, if you want to be prudent now and you’re not completely confident in the security that’s built into the portal then you might want to just limit the kind of information that’s made available.
Brian: Okay. Stage two meaningful use, the final rule introduced new core objectives for eligible professionals, eligible hospitals, and critical access hospitals. For eligible professionals only. One of the core objectives now is to provide patients the ability to view online, download, and transmit their health information within four business days with the information being available to the eligible professional.
Again, I have some issue with the way that’s worded. I pulled that from the final rule. I have some issue with it because of, again, some lack of specificities erring in terms of what they mean by health information. I’m presuming that’s going to be ferreted out but, the point on this is if you read that, that’s a pretty broad level of annexes in talking about viewing, downloading, and transmitting their health information.
One thing to keep in mind is, once you’re provided the information to the patient, the patient can do what he or she wants with it and that you’re not responsible for that once it’s delivered to them. It’s up to them as to who they want to share the information with. That’s the requirement under meaningful use stage two. For eligible hospitals and critical access hospitals, it’s the same but, to provide it within 36 hours after discharge from the hospital.
It’s also a fairly tight turn around. I’m not a physician but I would suspect 36 hours after discharge or maybe if your system is efficient and that information gets inputted directly into some database the minute that it’s ready and completed, that might not be such an issue. It is a fairly tight turnaround.
The last one is there is a core objective for eligible professionals only that it’s not really patient portal direct necessarily but to use secure electronic messaging to communicate with patients on relevant health information. Potentially, that core objective could be built into the portal itself so that you have an electronic messaging function in the portal so that you could comply with that, through that mechanism.
When we talk about personal health records, these are typically offered by third party vendors. They don’t have to be but, again, I’m sure many of you know that there are some large vendors out there who have been in the personal health records market for a good period of time now. You could develop your own proprietary personal health record if you wanted to do that. There are vendors out there who are skilled and have been doing it for a period of time. PHR is really a potential mechanism for shifting patient portal security challenges to the PHR mandate.
It is not uncommon and maybe common that covered entities that want to establish patient portals will partner with a third party vendor or a personal health record vendor and use that mechanism to create the patient portal. The reason that it is a potential mechanism for shifting that patient portal security challenge to that vendor is PHR vendors may now fall within business associate definition under HIPAA. This was part of the final omnibus rule that came out in late January and, if the PHR vendor is in fact acting as a business associate, the PHR vendor would both have direct liability under the privacy rule, security rule, and breach notification rule as well as whatever liability is negotiated between the covered entity and the PHR vendor under a business associate agreement.
The test, general test for whether a PHR vendor is acting as a business associate commentary speech to whether they are acting on behalf and providing that personal health record on behalf of a covered entity. If they are, the view is they are acting as a business associate.
Brian: We want to identify and manage the risks that are associated with patient portals. In a lot of ways, they’re not different from what’s already out there in terms of privacy and security. If you do have the HIPAA privacy rule in this context, this is really not a direct concerns in the patient portals involve, the delivery and access of PHI to or by the patient, okay? Again, the privacy rule is aimed at what covered entities and business associates can do with Protected Health Information outside of the patient. That’s between providers. That’s between labs, hospitals, and health plans. How they are allowed to use the information without authorization and when they need to obtain authorization for the use of the disclosure of that information.
Because, with patient portals, we’re talking about communicating directly to the patient, the HIPAA privacy rule is not directly implicated. However, the HIPAA security rule is directly implicated and is a direct concern. If you are providing a patient portal, you have to ensure that you have the appropriate safeguards in place to ensure the security of the information that’s being transmitted over that portal.
Again, if you elect to use a PHR vendor, you have to have them sign a business associate agreement and, through that business associate agreement, you can attempt to contractually shift the risk for a bridge of unauthorized exposure. Now, can you do that in every instance? Well, that’s going to depend on the parties that are involved. It should depend in part on who really has control over the PHI. In my view, in circumstance where you are outsourcing that function to a PHR vendor, there ought to be an instance where you could negotiate more of a risk shift to the PHR vendor.
The argument being that we’re hiring you to handle this portal for us. You understand that, in doing that, you’re going to be accessing, storing, and transmitting Protected Health Information. As a consequence of that, you are ready to be HIPAA-compliant in what you’re doing so you need to have the physical, technical, and administrative safeguards in place to protect that information. As a consequence of that, we’re going to say to you, meaning covered entity to PHR vendor, that if there is an authorized disclosure, you’re going to be responsible for it and you’re going to be required to indemnify us for that.
Now, will that be a successful negotiation for the covered entity in every case? It depends again. I can’t say for sure. I expect that there are PHR vendors out there who would argue to the contrary that their financial model will not support taking on that kind of risk with every one of your clients. Again, it’s an issue that would need to be discussed and sorted out between the covered entity and the vendor.
The next risk is the HIPAA breach notification rule and this is a direct concern if, and this is a big if, the Protected Health Information is unencrypted. I harp on this every time that I speak that, if nothing else encrypt your PHI … because if you do that and you do it consistent with the regulations that are out there that tell you what constitutes proper encryption, if you do that then you don’t have to worry about the breach notification rule under HIPAA. If you don’t encrypt it then you do have to be aware of the breach notification rule and you will be subject to that if there’s an issue with information transmitted over the patient portal.
You then have the various state privacy and data breach notification statutes. Let me talk for a second about state privacy laws. Under the state privacy laws, I can speak to the state of Michigan, for example, behavioral health information, mental health information as a subject to a separate statute. You need to be aware of that if you’re transmitting or storing any of that kind of information and having it accessible to the patient portal. You need to know that the requirements are there and ensure their compliance. And then, to state again the data breach notification statutes, the vast majority of states and I usually have the number wrong but I believe it’s 46 or 48 states now have data breach notification statutes and, certainly, Protected Health Information falls within the class of information that typically be covered as individually identifiable or personally identifiable information under those state statutes.
Brian: Additional risk, the failure to achieve meaningful use. I’m not going to spend a ton of time on this today because I think you could spend an entire hour or more talking about meaningful use, talking about CMS, of the incentives and the penalties and so on and so forth. Achieving meaningful use or not achieving meaningful use but there certainly are issues with failing to achieve meaningful use because, now, stage two of meaningful use includes the development of the online access for the patients that, clearly, this is something you need to keep in mind when you’re making your determination as to whether you want to open up a patient portal.
Lastly, there are potentially some professional liability issues and that depends on the information flow in the patient portal. What that really goes to is … this is maybe more generally. This is an issue that you see with blogs and chat rooms but you could see it here as well. What I mean by that is it’s one thing to push information out to prospective users where you control where the information is. Again, if you have a patient portal, you can design it how you want it. You can determine what information you want within that portal to make it accessible. You can place it in there and be relatively sure that you got it under control.
Where issues are starting to get created is where there are portals or any other kind of online process that will allow for the flow exchange of the information. What I’m really driving at here is to be cautious about physicians or other health care providers providing any kind of medical advice or receive medical advice through the use of the patient portal because, again, while I’m not a practicing physician, I do know something about professional liability requirements in the State of Michigan and, fundamentally, there’s this view that if you’re not going to diagnose the patient over the telephone or over the internet or something like that just being conscious about not getting involved in exchanges like that with a patient through a portal, remember again, you might offer information that could be perceived to be some form of diagnosis, that kind of thing.
Brian I’m going to talk a little bit about the breach of notification rule. I probably have more slides in here than we need on this but there were some updates to this through the omnibus final rule and I think it’s probably worth just ticking through these. A pretty big change in terms of the breach notification rule is the impermissible user disclosure protected health information is presumed to be breached. On last, the covered entity or business associate can demonstrate a low probability that the PHI was compromised. This really moves away from the old standard which was is there a likelihood of risk or harm.
It raises the bar for covered entities and business associates who turn to what they need to do when there is an impermissible use for disclosure of PHI. The burden shifts. You have to show that there’s a little probability that it was compromised. The covered entity or business associate has to conduct a risk assessment to determine if the PHI was in fact compromised. This, again, applies to covered entities and business associates. If a PHR vendor, again, meets the definition of business associates then it applies directly to the vendor and that’s, again, in addition to any contractual obligations that are contained in the BAA between the covered entity and the PHR vendor.
Brian: In conducting the risk assessment, the requirement when there is a potential breach the nature and extent of the PHI involved. This includes the identifiers and the likelihood or re-identification of the information. Again, you then go back to what is it that you want to allow in that patient portal. You have to consider the recipient or the unauthorized recipient. Is that recipient already under a HIPAA obligation. If so, that might lower the probability. If it was the PHI that actually requires a review, there are times when it appears that there might have been impermissible user disclosure at least an unauthorized disclosure where there wasn’t any actual viewing of the information. And then, finally, the extent to which the risk is communicated. What efforts have you undertaken if you let this happen to mitigate the risk?
If you have a breach and you have to provide notification, when you knew or by exercising reasonable diligence would have known then you have to disclose without unreasonable delay and, in any case, not more than 60 days after its discovery. There may be exceptions for law enforcement in which case the law enforcement does not want you to disclose in order to investigate. And then, the content of the disclosure: what happened, when it was discovered, the description of the compromised Protected Health Information, the steps the individuals should take to mitigate the effects and then the steps you are taking into your covered entity and your contact information of someone who is managing that process.
In extreme cases, there has to be notification of the media if there’s unsecured PHI with 500 or more affected individuals in any one state, you have to do that notification within 60 days maximum and it has to be done through a prominent media outlet which will depend on the market that you’re in. Press release of the covered entity’s website does not meet these requirements, you can’t just create your own press release to get on your website and say you’ve done a public notification. Again, it has to be done through a prominent media outlet.
And then, again, in extreme cases, there has to be notification of the Secretary of Health and Human Services if there are more than 500 affected individuals anywhere. Meaning, not just in one state. You have to do this immediately. Meaning, at the time the individual notices are sent. If it was less than 500, you have to maintain a log and report on the HHS website annually within 60 days of the end of every year. The HHS website has a form that you can fill out online and you have to do that again within 60 days after the end of every year with respect to these breaches.
Notification by a business associate, the business associate’s knowledge of a breach is imputed to the covered entity if the business associate is an agent of the covered entity. This is important in the context of a patient portal and a covered entity engaging a PHR vendor for this purpose. Agency law is a little bit complicated, it’s fact-specific, it’s state-specific but I think you want to be careful if you are, again, outsourcing the patient portal function to a PHR vendor. In that case, you want to be pretty clear that that PHR vendor is not your agent, okay? Now, you can say that in your business associate agreement. Most of them do say that.
Again, it’s a fact-specific inquiry. What you want to avoid is giving a PHR vendor any ability to speak on your behalf. Meaning, the covered entity’s behalf. It really should be treated as just a contracting entity with you, given no apparent authority to act on your behalf. They are not your agent. Because, if they are your agent and there is a breach, they know all about it and they don’t tell you about it, that business associate as your agent has imputed the issue. The clock may be ticking and you wouldn’t even know. Otherwise, the CE, covered entity’s clock begins upon receiving notice from the business associate.
Brian: The Federal Trade Commission also has the health breach notification rule prior to the adoption of the HIPAA omnibus final rule. This was probably more important prior to that time because, prior to that time, it was not clear the PHR vendors for business associates and, because of that, the FTC adopted this health breach notification rule to protect individuals who have personal health records, whose information were kept in personal health records. That’s how FTC’s rule applies to PHR vendors, PHR-related entities, and third party service providers. It is, though, preempted by the HIPAA breach notification rule if the PHR vendor is acting as a business associate and my view is nine times out of ten, maybe 99 times out of 100, when a PHR vendor is engaged by a covered entity, they’re going to fall within the definition of business associate. They need to know what a HIPAA breach notification rule is.
If that’s not the case, they still fall under the FTC’s breach notification and, in that case, they have to notify each individual who’s a citizen or resident of the United States who is, again, unsecured PHR identifiable health information was acquired by a non-authorized person as a result and notify the FTC. Again, I go back to the unsecured aspect of that secure your PHI or, in this case, PHI identifiable information.
Under the FTC breach notification rule, all notifications shall be sent without unreasonable delay, no case more than 60 calendar days. The vendor of personal health records shall provide notice to prominent media serving a state of jurisdiction following the discovery. If unsecured PHI identifiable health information of 500 or more residents of the state, again, very similar to the HIPAA requirement.
April, I’ll just read one quick thing. This is from the commentary in the HIPAA omnibus rule. It says, “To address those limited cases where an entity may be subject to both HHS’s and the FTC’s rules such as a vendor that offers PHRs to customers of a HIPAA covered entity as a business associate and also offers PHRs directly to the public. Both sets of regulations were harmonized by including a safer, similar language within the constraints of the statutory language. Again, there was an attempt to harmonize between HHS and FTC. The intent is not to make undo burden on PHR vendors that they have to know an all new significantly different breach notification rules and regulations.
Stage two meaningful use, we touched on this. The core objective is include the online patient access, the failure to achieve meaningful use within prescribed timeframes will result in CMS accessing penalties. Not only not getting the benefit of the incentives but, in fact, be penalize for meeting meaningful use and then according … I want to stop here for a second.
I’m on the mHIMSS legal task force and we had a call yesterday. There is some legislation pending … I don’t know how far along it is in the process right now but there is some legislation pending aimed at giving some relief to solo physician’s practices, physicians that are nearing retirement age, that kind of thing from the meaningful use requirements. Again, I don’t where that is but it is in, I believe it is in the Senate right now. As of today, the cow has left the barn on this. Again, if you don’t want to achieve meaningful use, then not only will you not achieve the incentives but you will face some reduced payments from Medicare, Medicaid.
Finally, my point on this is it would seem to me that it would make a lot of sense to coordinate this obligation, the meaningful use achievement, with the other patient portal objectives and risks integration of all of these efforts. One thing I don’t see is that when I’m reading literature out there right now, I’m not seeing a ton of … okay, patient portals are here. We’re going to need to go down this path. Alright, here are the five key things that we need to be thinking about, meaningful use stage two. What really is going to be required of us to achieve that? Maybe we start there as the baseline and then build off of that looking at the other risks and incentives that we have for developing that patient portal to determine really what we want it to look like, how robust we want it to be or maybe how narrow we want it to be but, again, it might be you need to coordinate all of these things and look at them holistically. Look at them together when determining how your patient portal is going to look.
Brian: What are some risk mitigation techniques? Surprise, surprise. My number one is to encrypt your PHI. I do really think at this day and age, that goes without saying it is not difficult to do. There are plenty of options out there for getting that done. Number two is when you’re looking at moving in this direction in developing a patient portal, you should reassess if you’re HIPAA compliant. I suspect that not most of you listening to this right now are already doing that anyway with the release of the omnibus final rule. The actual outside compliance date now is September 23rd of this year. I know that there were many business associates who were operating on let’s wait and see what happens. Now, we know what happened and the directive is pretty clear. You may already be in the process of reassessing where you are in terms of HIPAA compliance. Perhaps, you then add into that … alright, if we’re going to add a patient portal to our offerings here, what, if anything, should we be doing with our policies procedures, how to safeguards, that kind of thing as it pertains to rolling out a patient portal.
If you’re developing a proprietary portal, meaning you’re not going to partner with a PHR vendor, you should determine again the information that you want to make available. Secondly, I didn’t really get into much detail on this but you should, in all cases with patient portals, have the patients either sign or click through an acceptable user agreement for that portal. That’s important and it’s fundamental. With all the forms in spaces you have to sign these days, it would be expected at this point but getting the rules on the roll to the patient in terms of why they’re being granted the access, how you expect them to use it, things like that, guidelines, maybe you put in there some guidelines for them how to make sure that they’re not doing anything stupid in terms of where they access.
I’m a little bit on the fence on that because once you start getting advice, it turns out being bad advice. You’re going to be on the hook for it. The bottom line is you need to have a statement as to why it’s being provided to them, what the acceptable uses are of that portal, who should have access, the concepts of the password, username, password, that kind of thing.
If you are using a PHR vendor, negotiate your BAA provisions that are appropriate to your risk profile. We’ve talked about that. And then, lastly, ensure that the staff understand the properties of the portal and especially, again, authority to the delivery of medical advice through the portal without examination. There are AMA guidelines for physicians-patient electronic communications. If you haven’t looked at them, it’s probably worth a look at those as well.
Brian: This is, as I say, the most important slide of the presentation. Kidding aside, its says an informational presentation is not a legal or professional advice. I’m sure you all recognize that. Finally, my contact information is on the last line. I know Online Tech will be posting these after the presentation today. The slides, you’ll have access to them. Again, there’s my contact information and I left about 15 minutes which is probably good. Thank you all for listening.
April: Thanks, Brian. That was a great overview. I know we have a few questions here. I’ll invite anyone who has additional questions to share those with us in the last few minutes here. If we can’t get to all the questions, we’ll be sure to pass those along to Brian for follow-up with you.
A couple of questions here. Brian, I know that you bolded and have emphasized during today’s presentation to secure PHIs. I just want to make sure that I’m understanding the implications of encryption. If a covered entity or business associate has taken the precaution to encrypt health information and someone is still able to penetrate the server and access PHI, does that mean that they are no longer under responsibility to report that under the breach notification rule?
Brian: That’s correct.
April: Okay. I can get an understanding now why.
Brian: As long as it’s encrypted in accordance with the guidelines they are provided by HHS. I don’t have the copy of that. There was some guidelines that came out in November 2012. I don’t have that in front of me but you can access it readily on the OCR’s website, the Office of Civil Rights. If you follow the guidelines for encryption … NIST is involved in this. If you follow them and you have met the obligation, if some hacker comes out and is able to nevertheless grab that encrypted information and de-encrypt it, there’s nothing you can do about that. I would also say that if you knew that happened, that someone grabbed the information and it was encrypted but you then knew that they de-encrypted it, in an abundance of caution, I would certainly pick up the phone and contact someone at OCR.
April: Okay, to answer your point. Leon Rodriguez said, “Never held it against anyone to call and ask questions.” It seems they are pretty receptive to answering those questions.
Brian: That’s right.
April: Okay, another question here. It’s not directly related to patient portal but is related to security. If an organization is hosting a patient call reminder system and daily call reports are being sent to providers with the patient’s name, phone number, appointment time, provider and appointment type, is this a breach of security or privacy rule? Note that the e-mail is not secure or encrypted.
Brian: Will you repeat that? Sorry.
April: Yes, that’s okay. If an organization is hosting a patient call reminder system and daily call reports are being sent to providers with those reports including the patient name, telephone number, appointment date and time, provider and type of appointment, is this a breach of any security or privacy rule?
Brian: Well, I’m assuming by the way that question was phrased that the call center has not signed a business associate agreement with the providers, okay?
April: Good question.
Brian: Now, I hope you know the answer to that.
April Sage: No, I do not.
Brian: Number one, the provider should have a business associate agreement in place with the call center, okay?
Brian: No question about it. If they have a business associate agreement in place with the call center, then they’re covered. If they don’t, they need to in terms of preventing that from happening because I view the call centers as business associates. They are performing services on behalf of covered entity that involves the exchange of Protected Health Information, okay?
Brian: If the covered entity has not had the BAA in place, then that is a violation of HIPAA. I want to be a little careful here because this sounds like an actual fact pattern. It might be existing out here right now. I’m talking in generalities right now but my view is, again, the call center is acting as a business associate by providing those services. If that’s the case, the covered entity has an obligation under HIPAA to have a BAA in place to that service provider, okay?
Brian: The purpose of that BAA is obvious. There are several but the obvious fundamental purpose is to direct the BAA in terms of readily to authorize use of that PHI if there are restrictions against unauthorized use of the PHI.
April: If a BAA is in place then it sounds it’s left the questions such as is there a need to know for that information?
Brian: You always have to know that the minimum necessary provisions of HIPAA as well. How the amount of information are ought to be gathered and used by. Any business associates should be at the minimum necessary. There are exceptions to that. Generally speaking, that’s the rule.
April: Okay, great. Well, hopefully, we’ve answered that question and, if there is additional follow-up on that, please send it along and we’ll follow-up with you. Let’s move on to the next question. What is the requirement as far as a hosting company is just having a dedicated server sufficient in a hosting company or does the hosting company need to be HIPAA compliant? I did not say this person to generate this question.
Brian: I think April is the one who needs to answer that question but there’s a lot of discussion in the omnibus final rule about posting providers by providers, whatever terminology you want to use for it. Where HHS has come down is they have a pretty strict interpretation. What they’ve come down and said is if you are a host and you potentially have access to Protected Health Information, in other words, if you’re something other than just a mere conduit for that information to be ajar, you’re going to be falling within the definition of a business associate. The minute you fall within the definition of business associate under the new omnibus rule, you have to comply with HIPAA, okay? There are certain elements of the privacy rule that you do not have to comply with but, the security rule, you do have to comply with. Again, there was a ton of commentary on this for obvious reasons. There are a lot of hosting providers out there who really weren’t sure where they were falling on this continuum. HHS has been pretty clear again in the final rule that the expanded definition of business associate will generally include those kinds of hosting providers.
I’ve got the rule here in front of me while we’re talking. I’ll try to find the exact language here but, again, it is a fact-specific inquiry. You have to look at it case by case but, if you’re acting in any manner that might allow you access to PHI. I suspect this happening right now. I know it’s happening right now. Covered entities that are using host providers are now demanding that they sign BAAs. In the past, there’s been, again, discussion on that point. In some cases, maybe they weren’t signed because there was an awful argument that the host didn’t fall within that category of service provider but, now, the weight has shifted in the other direction. CEs, again, because they have an obligation to have BAAs in place with their business associates are forcing the issue.
April: Good point. I like your answer Brian.
April: Okay. Here’s the next question. The data in our patient portal is transferred back and forth with the patient through an SSL or Secure Socket Layer. However, data stored in the database is not stored in an encrypted state. The database server is not accessible to the outside world. Does the data we’re storing in the database need to be stored in an encrypted state?
Brian: The question is it’s encrypted in transit but not at rest. Yes, don’t know.
April: Good question. We'll get back with you on that.
Brian: Good question. Good question. I’ll dig into it a little bit. Don’t know. My follow-up question to that would be why is it not encrypted when it’s stored.
April: For the person who asked that question, I have some other feedback that I’ll show you after the webinar as well. Let’s see. A number of physician offices still use unencrypted fax for transmission of documents. How does it measure up with the regulations?
Brian: Well, if it’s not encrypted and the information gets intercepted by an unauthorized user then it’s breach. You have to follow the breach notification rules at that point. I don’t know if that’s the question in terms of measuring up but when you’re transmitting Protected Health Information, if you’re not doing it in an encrypted manner, if it’s intercepted, then it’s a breach and you have to follow the breach notification requirements.
April: It certainly creates extra liabilities. Okay, what’s the definition of a conduit?
Brian: To me, a conduit is, again, we represent … I won’t say who it is but we both worked for the health information exchange for a while. This issue is near and dear to our hearts. Conduit is, just the best analogy I could give to that is that it’s a pipe. I know that’s really not helpful. I do want to find the actual language from the final rule where they speak for this but it’s like a clean pipe where you’re providing that. And so, you’ve got entity A on one end, entity B on the other end. You’re the owner of the pipe and you’re saying, “You can use this pipe to send your information from A to B or B to A but we’re not going to have any ability to access that Protected Health Information. It’s just going to flow through that pipe by us or if we’re sitting at the hub of a wheel or whatever. It’s just going to come in and go out. It’s not going to reside anywhere where we can access it.” That is what a true conduit is.
If you have a circumstance where you have a colocation facility and, let’s say, you have a public cloud, let’s say, you have a private cloud, if there’s an ability for you as the provider of that to have access to the PHI that’s on there, then HHS view you as a business associate whether, in fact, what you are doing for the covered entity really requires you, I should put it that way, to access that.
April: Yes, I know from our perspective that while we maintain the strictest policy of confidentiality and triple pinky swear we never, ever show, view a patient file so that we wouldn’t know necessarily what’s PHI or not, at least from our perspective, we know that we are not a conduit as a hosting provider because, should we have an error with the employee, we know that there does stand some chance that someone could view that data. At least from our business associate perspective, that’s how we look at it, too.
April: All right, next question. One more. Do you have time for one more quick one, Brian?
April: As an EMR vendor, should we have business associate agreements with contracted developers or are they considered sub-contractors under us?
Brian: Yes, I think they would be sub-contractors under the final omnibus rule. The business associate who’s contracting sub-contractors has to put in their contracts sub-contractors what the obligations are in terms of protecting the PHI, if performing their sub-contracting activities, they are required to or may have access to that PHI. Okay?
That is, again, a change from before that’s an amendment to HIPAA but, again, the business associate, when they put their sub-contract together for that sub-contracting entity, they have to identify in that sub-contract what the requirements are, limitations and restrictions, are on the use and disclosure of that PHI.
April: Super, okay. Thank you, Brian. If there were any questions that we were not able to answer today, please accept our apologies and we’ll forward those onto Brian. Please feel free to contact us at firstname.lastname@example.org or Brian at the information on the slide. Thanks so much for joining us. We welcome your feedback. We’d love to improve our webinars and learn what topics are important to you. Join us on Tuesday at Two May 7th to learn more about mobile security in the PCI environment. Everyone have a great day.
Brian Balow, Attorney, Dickinson Wright
Brian Balow concentrates his practice in the areas of IT, healthcare law, and intellectual property. Brian has worked with Fortune 100 clients over the last 15 years on IT-related matters, including the drafting & negotiation of agreements, formulation & implementation of policies & procedures for the management of IT (including outsourcing-related issues), counseling & advising on privacy & data security issues, and assisting clients in favorably resolving disputes with IT vendors (including disputes with the BSA and SIIA).
More recently, Brian has spoken and written extensively on healthcare IT and telemedicine issues (including HIPAA/HITECH issues). In 2012, Brian presented on social media in healthcare issues at HIMSS12 in Las Vegas and to the National Council of State Boards of Nursing in Idaho, on regulation of mHealth technology at the SoCal HIMSS Health IT Innovation Summit in Yorba Linda, California, and on BYOD issues at the HIMSS mHealth Summit in Washington, DC. In December of 2011, Brian contributed the chapter entitled “Allocation and Mitigation of Liability” to the ABA Health Law Section’s “E-Health, Privacy, and Security Law” treatise.
Brian is a 1988 cum laude graduate of the University of Georgia School of Law, where he was twice a scholarship recipient and was Managing Editor of the Georgia Journal of International and Comparative Law. Following graduation, Brian served as a judicial law clerk to the Hon. James Harvey in the United States District Court, Eastern District of Michigan.