AHLA's Speaking of Health Law

Privacy and Security Risks of APIs

• AHLA Podcasts

Share episode

Jon Moore, Clearwater, and Iliana Peters, Polsinelli PC, talk about the importance of application programming interfaces (APIs) in connection with health care data. The podcast discusses the recently issued OCR final rule and how the rule impacts APIs. The speakers also discuss common vulnerabilities associated with APIs and give practical tips on steps an organization can take before implementing an API. Sponsored by Clearwater.

New Health Law Daily Podcast Coming in January 2025

Coming in January 2025, AHLA’s popular Health Law Daily email newsletter will also be available as a daily podcast, exclusively for AHLA Premium members. Listen to all the current health law news from the major media outlets on this new podcast! Subscribe Now

Speaker 1:

Support for A H L A comes from Clearwater, the leading provider of enterprise cyber risk management and HIPAA compliance, software and services for hospitals, health systems, and their business associates. Our solutions include our proprietary software as a service-based platform, I R M Pro, which helps organizations manage cyber risk and HIPAA compliance across the enterprise. An advisory support and manage services provided by our deep team of information security and compliance experts. For more information, visit clearwater compliance.com.

Speaker 2:

Hello, I'm John Moore, chief Risk Officer, and Senior Vice President of Consulting Services at Clearwater. And I have with me here today, Eliana Peters. Eliana, would you like to introduce yourself?

Speaker 3:

Thanks, John. Hi, everyone, this is IA Peters. It's nice to be with you today. Um, I am a shareholder in the Washington DC office of Polson Alley pc, which is an AmLaw 100 law firm. Um, before joining Polsinelli about almost three years ago, I was, um, at the Department of Health and Human Services in the office, first Civil All Rights, which is the office responsible for HIPAA enforcement. And most recently there I was the acting deputy director. Um, John.

Speaker 2:

So Eliana, as you know, one of my favorite things to do is to talk with you about current events and issues related to healthcare, cyber risk and, and privacy. And today I'm hoping to talk with you about privacy and security risks as they relate to APIs or application programming interfaces. How does that sound as a topic?

Speaker 3:

Always. One of my favorite things to do as well, John, is talk to you about current topics. It's a very current topic and not an easy one, so I'm happy to, to discuss.

Speaker 2:

All right. And great. So, so maybe we could start out with, uh, just talking about what is an a p i and, and why are APIs suddenly very important, uh, to data flow in healthcare?

Speaker 3:

Yeah, it's a really, really good question. Um, I think the easiest way to explain APIs, um, which are application programming interfaces, um, which is basically a fancy way of, uh, saying, uh, a program that allows different systems to communicate with each other and to share data. And so I think that's why APIs have become so important in healthcare and in other industries too, is because they really are, um, a way to facilitate robust communications and data sharing. Um, and you know, John, John, you know, and, and your team at Clearwater well knows the fact that there is so much work being done today about around data sharing and about data sharing and how to do that in a way that is, um, you know, uh, quick, efficient, um, and private insecure, which is obviously something that you and I are, are very concerned with. So, so these, these APIs are really part of the conversation because of the larger conversation about the best ways to share data for all different types of purposes in healthcare.

Speaker 2:

Right. And I, I think some, uh, uh, a, uh, explanation of API that I think may be helpful to this, this audience anyway, is sometimes you'll hear it referred to as a contract. Uh, so an a p i is a, an offer, and the offer looks something like this. If you send information to me in this well-defined format, I will then provide you with the following service, uh, or information in this described format. Uh, and so when someone or in a system then accesses the API or sends that information in the format, uh, required, uh, that's sort of an acceptance of that offer. And then when the service or data is provided back, that's fulfillment of the, of the contract. So sometimes I think that's a, a helpful, uh, way to think about this. It's, it's really just a, a way, a well-defined way, uh, for two systems to communicate. And as ia, uh, suggested, you know, I think that, uh, that in particular for, for some time now, probably the last decade, there's been, uh, uh, the, the belief that if we can just, uh, facilitate, um, the easy electronic or the easy exchange of electronic health information, uh, between, uh, healthcare providers and patients and, and payers, et cetera, everyone within the, the healthcare environment that, uh, we'll get two things. One is we're gonna get improved care, and the other is that we're gonna get reduced cost. And so it's, it, I think that, uh, we're starting to get to the, the point with, with, um, some of the requirements around APIs, which we're gonna talk about in just a second, um, that hopefully will start to realize, uh, some of those benefits that have reduced cost and improved care. And I think that's, uh, really where we're, we're sort of at in, in the conversation, uh, right now. So, uh, kind of getting to that, uh, ia, there's been, you know, there were two new final rules that came out. One from C M S and one from O C. So how do you think, uh, those rules introduced earlier this year are going to impact the use of APIs?

Speaker 3:

Right, right. Great question, John. Um, I think, you know, I think ultimately it remains to be seen, in my opinion, how, you know, how these new requirements, um, from, uh, cms, which is the Center for Medicare and Medicaid Services at O N C, which is the office of the national coordinator at hhs, um, really start moving this conversation along. And, and again, ultimately this is about more robust data sharing in a lot of different circumstances. And that can be data sharing between a healthcare provider of some type and a patient, or a health insurance company and a patient. It can be, uh, data sharing between healthcare providers or a healthcare provider to a health plan. Or it can be, uh, data sharing from these types of entities to the public or to, um, uh, different types of publicly available applications that, you know, a, a patient may want to use, for example. So, you know, the, the, the rules that came out from CMS and O N C are sort of taking, um, uh, basic steps to require, um, communications, like you were just talking about, John, these, these contracts having these sort of contracts in place to share this information in certain ways. And for example, CMS is requiring that certain payers, um, make certain limited information publicly available using a standard based api. So, you know, again, taking these, these steps to make sure that certain entities are enabling, um, the appropriate communication based on the use of these APIs. So, you know, sort of sharing directory information outside the entity based on a standards based API and, and making sure that that capacity exists and that certain entities are undertaking those. Um, and then, you know, the, the other things that, that the O N C is doing are really trying to support API certification criteria as well. And what that means is making sure that these electronic health record sets that we're using have certain functionality involving APIs. And so what that means, again, is to drill down even more, is making sure that certain, um, types of software, these that is these electronic health record software applications, can share certain types of data using APIs. Um, and, and in these cases, mostly for purposes of treatment or to provide access to a patient, to their own information. So for example, one of the criteria that O N C is supporting is, um, you know, uh, patient matching across, uh, different types of healthcare settings, sharing of clinical notes, um, and allergies and medication information, um, to make sure that once you've identified a patient across the system, the right information about that patient gets transferred to all the folks in that system that need access to that information. So they've, you know, uh, promulgated these different standards including, um, the, the fast healthcare interoperability resources standards, which is known as fire in association with these APIs. And in really trying to encourage folks to ensure that their software applications that interact with medical records are able to share information in a more robust way so that, again, patients get better care, um, and everybody has the information that they need to really make sure that the health health system works appropriately.

Speaker 2:

Yeah, I think, you know, APIs obviously have been around for quite a long time, and, and, uh, I think that the issue has been that many of the APIs that existed, uh, in the healthcare space were proprietary or, or closed in one way or another. And, and so they didn't truly facilitate the exchange of information except, uh, if you're using, for example, systems from the same vendor or, or, you know, there's a lot of lock-in, uh, type of, uh, economic approaches that let, let's call them to the use of APIs. And the, I think the hope is really to your point, by introducing these standards or requirements around the APIs to open that up, uh, to facilitate. Ideally, I think this was one of the objectives to facilitate competition, um, to facilitate, uh, opportunity for economic, uh, development as well as, as, uh, the, the freer exchange of healthcare information. And, and you know, that that goes to perhaps one of the, the newer, um, elements of this, and this is the, the patient access through third party applications through the api, which I want to, uh, talk to you a little bit, um, more about shortly. But, uh, before we get to that, um, Eliana, how does this relate? And, and I know there's been a lot of discussion, uh, recently in the industry about information blocking and a lot of concern about information blocking. How does this all tie into information blocking provisions?

Speaker 3:

Right, right, right, right. Great question. So information blocking is, is, again, part of the Office of the National Coordinators initiatives and part of the new rules that they've, that they've promulgated and information, really, sorry, information blocking is really about the activities that the office of the national coordinator expects entities to be willing to undertake, to share information. So again, we're back to the idea that in order for our health system to work, we need to really ensure that there is robust data sharing inappropriate ways and in private and secure ways. And we'll, I, I know we're gonna talk about that too, John, cause I know that's one of your concerns as well. But really, you know, making sure in, in circumstances where the data sharing is in fact appropriate, and that is between healthcare providers that are working with a patient or between a healthcare provider and a health plan, or with the patient themselves, that there aren't, um, any limitations, um, on what information can be shared for those purposes. When it's a, when it is an appropriate sharing of information, we wanna make sure that it happens quickly, efficiently, and in an electronic way from these certified EHR technologies. So again, the basis that we're talking about is these certified EHR technologies that are expected to really have this cap, these capabilities built in, um, and really, um, ensure that there isn't any, to your point earlier, John, there aren't any unreasonable barriers to sharing that information, um, you know, across different types of providers who use different types of EHR systems or with, for example, applications that the patient may wanna use as well. So it's not just, you know, EHR to EHR at the end of the day, even if those are two different types of proprietary systems, but, um, across health systems across different states and with different types of entities outside the healthcare system that may be, you know, providing services directly to the patient. Um, and so these APIs are really, um, being leveraged to, um, ensure that we can share this information as required by these rules that essentially prohibit unreasonable barriers to that sharing.

Speaker 2:

Yeah, I think that my impression is that, that there was, uh, the impression rightly or wrongly, or certainly at different degrees, that, that organizations were, were, uh, and by organizations I use that term broadly, that could be it, uh, certified health IT vendors or providers or other folks within the healthcare, uh, ecosystem that they were, uh, increasing switching costs and an attempt to retain customers, uh, through, by making it difficult, uh, for information to be exchanged outside of those organizations. At least. I think that was the, the perception that led to, uh, much of, of the, this legislation around kind of opening up the APIs and, and introducing standards as well as the information blocking provisions. Because when you look at them, uh, that seems to be where they're primarily targeted at. And, and, uh, then there's the exceptions that came to that, which, which I think are a recognition that there has to be some limitations on this for security and other reasons, the safety of patients and, and, and so forth that, um, that there is some limitations on the, that there are some circumstances in which, uh, there should be some limitations on, on, uh, or restrictions on providing information. So it's a really, uh, an interesting, uh, uh, I think area to, to look at. And it's gonna be interesting certainly to see how, uh, that unfolds, uh, sort of going forward and how enforcement, uh, will work in that space. Um, I mentioned earlier, Leona, you know, that the, this idea that there's going to be a plethora of third party applications, and at least my expectation is, and I think the expectations of, of some of the folks behind the legislation is that, um, those third party apps may be provided by, uh, organizations or companies that are not traditionally healthcare organizations, and that they be providing them directly to, to, uh, patients for their use or to the public for their use in maintaining their healthcare information. So that in particular brings up, I think, some, some conversations about HIPAA and, and how HIPAA regulations apply. But I think more generally, how does, how does HIPAA regulations factor into all of this, uh, with the APIs and the third party apps? And, and, and in addition to that, now we have more and more state regulations as well. Where do you see that all kind of playing out?

Speaker 3:

Yeah. Yeah, I think that's a really important part of the conversation too. Um, and it, it, it's, it's interesting because HIPAA does and does not apply to your point, depending on the entity that may be involved. So, um, the interesting thing about the way that we do data privacy and security in the US is that it's very sector specific. And so we have very clear rules in some cases for some types of entities depending on what kind of information they hold and, and less clear rules for others. So you may have a situation where you have a healthcare provider that is covered by hipaa, and you have a patient that wants to share data with an entity that's a wellness app, for example. And that wellness app is not covered by HIPAA because the vast majority of those types of third party applications that deal with wellness issues aren't, um, because HIPAA actually has a pretty limited jurisdictional scope and really deals with entities that either, um, provide health insurance or get paid by health insurance. So if we go beyond the hippo scope, then we may be dealing with different types of jurisdiction, like FTC certainly would have jurisdiction over those types of entities and their security practices. And FTC has been engaged in very robust enforcement, in my opinion over the last few years related to consumer promises, um, uh, related to security. But, you know, it's a different enforcement scheme. So, um, you know, it's really about trying to, I think trying to help consumers understand, um, what the different protections for their data, um, is in different circumstances, and making sure that to the extent that you as a particular entity are covered by a specific set of requirements, be it HIPAA or FTC requirements or state law requirements, were in some cases international, um, data privacy and security requirements that you understand how to comply with those in, in these new data sharing efforts. Um, and certainly, um, you know, from a HIPAA perspective, from an FTC perspective, and arguably from a state law perspective in many states, including, for example, California, those would include robust data privacy and security protections for the data. Um, not only, you know, in your hands, but when it's being transmitted and arguably in the hands of the recipient as well.

Speaker 2:

Yeah, I think, uh, uh, I, at least this has been my experience recently, particularly with all the, the covid, uh, situation that we have now. I see a lot of, uh, comments from the public, which suggest to me that they don't truly understand, uh, when HIPAA applies and when it doesn't, which isn't, which isn't terribly surprising. It can become, you know, somewhat complex if you're, if you're not a student of, of the HIPAA regulations. And, but I see that more and more frequently where there's this, there's this notion that if it's, if it's my healthcare related information, it's covered by hipaa and therefore I'm protected. And I think it's certainly not quite that clear. And to your point, uh, it becomes even more though. Well, this is my impression, and you can correct me if you have a different view. I, I'm sure you will, but the, the whole privacy, uh, the legal landscape and from a privacy perspective within the US is becoming more complicated, uh, by the day with, you know, with different state regulations that are going into place. Uh, usually HIPAA's excluded from those, but not, but it's not always so clear and, you know, it's, it's, uh, uh, or information that be covered by hipaa, but it's, it's becoming more and more challenging I think for, uh, for folks like yourself that are, you know, that are providing guidance in this space. And, and for, certainly for the, the, uh, just typical, uh, American out there who's, who's trying to understand, um, what limitations there are around the use of their information, uh, by organizations with whom they're, they're trusting that information to, uh, to understand what are the roles and, and how does does that, uh, how do they all play out or work together. Ia, we, you know, we've talked about, uh, about the APIs and you mentioned that certainly that that, that Clearwater and, and I personally have, you know, some concerns around security, and I know you have a security background as well, at least, uh, uh, to a certain extent. So, um, what do you think are the, the most common vulnerabilities associated with APIs that an, that an organization should be concerned about?

Speaker 3:

Yeah, I think it's a good question. I mean, I think, um, I think to your point, John, um, you know, the, the APIs are a tool and, and just like any other tools, I I, I hear this often with, with AI applications as well, um, they're, they're really only good as good as the entity that that built them. So, you know, when we're looking at APIs or when we're talking about contracts, you know, to your point earlier, you really need to consider the source<laugh> and really ensure that you, um, you know, that you understand exactly what the, um, what the, the api, the, this, the particular API that you're using does and, um, and has the capability to do so. Certainly if you, um, if you are a smaller provider, for example, and you're working with a reput reputable vendor to really help you enable these exchanges of health information in a way that is secure, it's encrypted, you know, you have these, uh, these rules of the road, including if you're using a fire standard API framework, for example, um, that, that you can, you know, you can rely on those, those interactions. Um, but I think similarly, if you are, um, working with, with less reputable entities, you may need to be concerned about how those, um, APIs are being implemented and their, their technical specifications and making sure that they do, for example, um, enable encrypted transmissions, um, and that your data is being protected when it's being exchanged, um, making sure that it's a, it's a known, a known entity in terms of, of, of how you're having those, um, quote unquote conversations or communications that involve your data. Um, so I think that that is sort of my general way of looking at it, but I'm sure John, you have, you have specific thoughts there too, and I'd love to hear your, your thoughts on this too.

Speaker 2:

Sure. I, I think, you know, the, the, the big one you've already touched on, and that is the, uh, the software itself and whether there's deficiencies that exist within in the software and, and, you know, uh, that comes down to, to your point, the rigor, uh, with which the organization created the api, uh, the rigor with which they engage in their, um, coding practices, including, uh, implementing security during their, uh, during the coding process itself, which unfortunately, many organizations are not particularly mature. Even the organizations that have, you know, been been developing software for some time, oftentimes they're not real mature in how they, uh, include or embed security within that process. And so, you know, as a result, a lot of times there's, there's bugs in the code or errors in the code or, or security defects within the code itself, uh, that can prove problematic. And, and we've seen that, um, we've seen that unfold numerous times and, and, and including recently, um, where, uh, you can have problems in the, in the code itself, and not necessarily a bug, but we have the solar winds issue right now where, um, someone was able to introduce, uh, essentially like a, a backdoor into one of their, uh, backups and or their official backup process. So it was pushed out to all of the software. So you need to be very careful about deficiencies or, uh, problems within the, the, the code itself or the software itself. Uh, another area where, where we'll often see issues is around authentication. So, uh, needless to say, in in many of these cases, in particular in the, in the case of the consumer third party apps, you're going to be exchanging some sort of credentials, uh, with the API so that it, it knows who you are and whether or not you have access to, to the information you're requesting. And if that exchange of credentials itself is flawed, um, those credentials might be visible, uh, to someone watching the traffic, which is another, you know, potential problem. Um, so, and kind of going before that, in terms of the lifecycle, how did I get those credentials? So how did I receive my password? Uh, how did I receive my username? Uh, is it, was it possible for someone to capture that information, uh, before I even got it? So they already have that, uh, information available to them. Uh, those are some of the things we see. Another issue, uh, that can come up, and this is more of a, from an availability, uh, perspective. So we think about confidentiality, integrity and availability, confidentiality being what oftentimes people equate with privacy. There's some subtle distinctions, but, but, uh, you know, who only allowing those people to see the information, who should be seeing the information comes, confidentiality, integrity, uh, being, I wanna make sure that, that there's not errors introduced or unauthorized changes being made to the information, which is particularly troublesome, uh, from a healthcare perspective. Um, and then the, the last being availability or accessing the information. And in that case, uh, you know, we wanna make sure that the a p i is built in such a way that it can handle volumes of traffic that it's going to receive so that it, you know, not, uh, a distributed denial of service attack or some other attack like that on the a p i, isn't gonna shut down access to it and, and, and prevent the exchange of information. So those are just some of the things, uh, there's, there's more, uh, specific vulnerabilities that can exist within, uh, these APIs. But those are just a, a few of the types of things that, that we, uh, typically look at, um, when we're looking at, at the APIs. And that's just, that's the API itself, that's not even thinking about vulnerabilities that might exist in the underlying infrastructure that are supporting the APIs, um, which are also, you know, obviously with something that you'd wanna, uh, be looking at as well. So that's, uh, that's sort of where we're, um, at when we, when we think about this. So aa I'll, I'll ask you one additional question, one more question. I always have one more question for you as you, as you know. Um, so if, if I'm an, if you're, if I'm a, a client of yours, a client organization of yours, I'm considering, uh, implementing the APIs, or I feel like I'm required to implement these APIs, I'm also concerned about, uh, these potential penalties associated with information blocking. What do you recommend I do? Are are there steps that I should be considering right now or should I should be taking right now?

Speaker 3:

Yeah, yeah. I, again, um, always good questions from me, John, and this is another really good one. Um, you know, I think, um, many times the, the level of diligence that we're talking about related to sort of vetting, you know, the API and the, um, and, you know, the security issues that may be present, et cetera, are, are sort of beyond the, the healthcare entities that we're talking about. And so it may be really helpful for entities, um, particularly when we're talking about the information blocking requirements, uh, from O N C and the interoperability requirements from CMS related to their certified EHR technology is to, um, as a first step really have a better, um, and more robust, uh, dialogue with their EHR vendor. So at the end of the day, these healthcare providers aren't the ones who are implementing a lot of this technology. A lot of this is coming from their electronic health records vendor that has the certified EHR technology. So it, it may really be worthwhile to sit down with the HR vendor and talk with them about how they are planning to implement these requirements related to APIs, what that means for the healthcare provider in practice. Um, you know, if there are additional concerns about security, having those conversations. But really, you know, again, starting with where the data's gonna be coming from, and in most cases, that will be at least start with the electronic health record system that you're using, um, and really try to get a good understanding of how the requirements are gonna be implemented from your vendor. Um, so you can work with your vendor on any issues you may ha you may have as a healthcare provider provider, or, you know, in some cases a patient having those conversations, in some cases a health plan or, or other, um, related health system entity that may be, um, interested in getting, um, data as part of that process. Um, so in many cases, that's what I'm recommending to my clients these days is, is really, you know, given we're shooting for an April, um, deadline with regard to compliance with these CMS and O N C requirements, is using that time to sort of not only digest the requirements themselves from an, from an intellectual standpoint that is reading the rules and figuring them out, but really having conversations with your vendors to understand how they will help you implement these requirements and how they anticipate the technology to work.

Speaker 2:

Yeah, you bring, bring up a, a number of good, so, so, uh, very, I think important point that, that in many cases are not, if not most cases, the, that, uh, the healthcare organizations themselves are looking to third parties to, to implement a, a lot of this technology, and that's not that unusual for them. Which brings up a number of issues, which I think you've touched on. One is, uh, understanding the, the risk of the vendor. Um, so vendor risk management, sometimes called supply chain risk management or business associate, uh, risk, uh, you know, understanding, uh, who it is that I'm working with, uh, to implement the APIs and any risks associated with with that vendor. Um, the next is understanding the, you know, from our perspective, the risk risks that are introduced through implementation of the API and understanding, uh, for example, um, you know, what's the system is that it's that the API's associated with, and if it's an e r, you know, obviously that's perhaps the, if there's a crown jewel of crown jewels within a healthcare organization, it's our eh r system. So, you know, obviously the, the potential impact of a breach, uh, is extremely high. Um, so what we need to be very concerned with is the likelihood of that breach occurring. So, uh, you know, we're looking at what controls have been put in place, uh, around that a p i or, or implemented within that a p i to reduce the risk, uh, of a breach, uh, to our E H R in particular. Um, so we, we know we wanna look at that as well to understand what those risks are and whether or not appropriate controls are in place. And, and of course for us, you know, the final, uh, step if there is really is a final step. It's more of a process actually. But, you know, an ongoing process, as you've pointed out on numerous occasions of managing risk is that we want to then be testing those controls. So we want to test those APIs, uh, to make sure that, that the controls or safeguards that are in place are operating as designed and functioning as expected, uh, and, and actually, uh, um, doing their job of, of reducing or, or mitigating the risk to our organization and perhaps more importantly, to our, to our patients. Um, so thank you very much, Eliana. It has been a delight. Our time is running out here. So do you have any final, uh, final thoughts you'd like to share with everybody?

Speaker 3:

I don't think I have any final thoughts on this particular issue. I just wanted to say again, thank you, John, for the conversation, um, and the, and the robust discussion and, and I hope people find, um, all the information here really helpful.

Speaker 2:

Well, thank you again, and thank you all for, for listening today. Again, I'm John Moore, chief Risk Officer and Senior Vice President Consulting for Clearwater. And we are, uh, delighted that we could share our conversation with you today. And, uh, thank you very much.