In August 2009, the Federal Trade Commission (FTC) issued the Health Breach Notification Rule (Breach Rule), which requires vendors of personal health records and related entities to provide notice to consumers following a breach. After over a decade without any enforcement of the Breach Rule, the FTC issued a policy statement in September 2021 clarifying that health apps and connected device companies must comply with the Breach Rule. Jon Moore, Chief Risk Officer and Senior Vice President of Consulting Services, Clearwater, speaks with Ty Kayam, Attorney, Microsoft, and Adam Greene, Partner, Davis Wright Tremaine LLP, about the history of the Breach Rule, the FTC’s new interpretation, and potential future enforcement. Adam and Ty recently authored an AHLA Briefing on this subject. From AHLA’s Health Information and Technology Practice Group. Sponsored by Clearwater.
To learn more about AHLA and the educational resources available to the health law community, visit americanhealthlaw.org.
In August 2009, the Federal Trade Commission (FTC) issued the Health Breach Notification Rule (Breach Rule), which requires vendors of personal health records and related entities to provide notice to consumers following a breach. After over a decade without any enforcement of the Breach Rule, the FTC issued a policy statement in September 2021 clarifying that health apps and connected device companies must comply with the Breach Rule. Jon Moore, Chief Risk Officer and Senior Vice President of Consulting Services, Clearwater, speaks with Ty Kayam, Attorney, Microsoft, and Adam Greene, Partner, Davis Wright Tremaine LLP, about the history of the Breach Rule, the FTC’s new interpretation, and potential future enforcement. Adam and Ty recently authored an AHLA Briefing on this subject. From AHLA’s Health Information and Technology Practice Group. Sponsored by Clearwater.
To learn more about AHLA and the educational resources available to the health law community, visit americanhealthlaw.org.
Support for HLA comes from Clearwater, the leading provider of enterprise cyber risk management and HIPAA compliance saw software and services for healthcare organizations, including health systems, physician groups, and health. It companies, our solutions include our proprietary software as a service based platform, IRM pro, which helps organizations manage cyber risk and HIPAA compliance across the enterprise and advisory support from our deep team of inform and security experts. For more information, visit Clearwater compliance.com.
Speaker 2:Hello, I'm John Moore, uh, chief risk officer and senior vice president of consulting services at Clearwater. And I have here with me today, Ty KM and Adam Green. Uh, Ty Adam, perhaps you'd like to introduce yourselves.
Speaker 3:Great. Thank you so much for having us today, John. Um, my name is to Kayam. I'm an attorney in the corporate external legal affairs department at Microsoft and I specifically support health and life sciences and retail health, where my practice has a dual focus of digital health technology transactions and health regulatory, and product counseling. Uh, before we jump in, I just wanna share that all viewpoint and opinions are my own and not, um, attributed to any organization with which I'm affiliated and Microsoft.
Speaker 2:And I'm Adam Green. Um, thanks also, John, for having us today. So I'm a partner in the Washington DC office of Davis Wright Toma. Uh, my practice focuses on health inform privacy security, um, when it can't be stopped, breach response and information blocking. Um, and prior to joining DWT a little over 10 years ago, I was with HHS, um, including with respect to when some of the rule making under the FTC, uh, was occurring that we're gonna be talking about. So, yep. Looking forward to this. Thanks guys. So, uh, and Adam, you, you sort of touched on this. So on August 25th, 2009, the FTC issued the health breach notification rule. And it's been over a decade now without any enforcement of the rule, but, uh, recently the FTC issued a policy state, I guess it was September of last year clarifying that health apps and connected device companies need to comply with the role. And following that in February of, I guess it was this year, Adam, you and Ty published a briefing on American health law.org, discussing the history of the health FTC health breach notification rule in the FTCs, let's say perhaps new or expanding interpretation of that law. Uh, if it's okay with you guys, I was hoping today we could talk about your briefing and the potential future of enforcement of the FTC breach role. Let me start with you, Adam. I, I think most people listening are likely familiar with the HIPAA breach notification rule. Certainly that's got a lot of press over the last decade, but maybe not so much with the FTC rule. What's the origin of the FTC health breach rule and, and what does it require?
Speaker 4:Sure. So both the HIPAA breach and notification rule and the FTC health breach notification rule were products of the high tech act. So you have to kind of rewind to 2009. And so someone at that point told Congress that the next big thing was personal health records. So the concept was instead of having a box of hard, you records in your basement from your different doctors, uh, from your different medical providers, you would have an electronic app that would store all your different medical records from different healthcare providers have them instantly accessible, allow you to share them with others. The big players at the time were actually Google, which had an, a PHR, um, Google health, um, they've since recycled that name, I think once or twice, um, and Microsoft, which had, um, at the time health fault. And so Congress, I think was really kind of told that there's these PHRs these personal health records that are oftentimes not regulated by HIPAA. They, they would essentially only be regulated by HIPAA if they're being off by a HIPPA covered entity, like a healthcare provider or a health plan, which most times would not be the case and that there was this potential for all of this sensitive medical information to be in these PHRs and unregulated. And so in the high tech act, in addition to creating a breach notifi and rule with respect to HIPAA, Congress went ahead and created what they even termed in the title, a temporary health breach notification rule with respect to PHRs. Um, and they assigned that to the FTC to draft that rule. And so the FTC not long after went ahead and created final rule, um, implementing this high tech act provision and providing for breach notification by PHR vendors. So those who actually create the PHRs and various entities that might be involved in that kind of PHR ecosystem.
Speaker 2:Certainly again, we've seen, uh, enforcement by OCR on the HIPAA breach notification, but, but we haven't seen enforcement on the FTC side, but that doesn't mean necessarily that they've been silent on the issue of consumer health data. And in your briefing, you reference a couple of FTC blog articles. Can you tell us a bit about, more about what those blog articles, uh, contained and, and what they revealed about the FTCs thinking in this area of, uh, health information?
Speaker 4:Sure. So HIPAA has always had this issue that it only applies to HIPAA covered entities and after the high tech act business associates, and that if you are none of the above, you could have the most sensitive health information in the world, but you are not regulated by HIPAA. And so the FTC, I think, recognized this regulatory gap, um, fairly early and has looked to essentially, you know, used general authority under section five of the FTC act, which prohibits unfair and deceptive trade practices to fill this gap and make sure that, um, vendors in this space, um, are, do not participate in unfair deceptive trade practices with respect to the privacy and security of the data that they receive. And so the FTC has kind of put down its flag for quite some time, um, that they do have authority to regulate, um, consumer, uh, consumer or purposed health apps. Um, and that included that they, that the FTC put together a seminar on consumer generated health and information. So all these apps that, um, collect information or generate information on the consumer side, outside of HIPAA. So they had a seminar on that, um, with a number O of different presenters talking about different aspects of the issue. Um, and they went ahead and followed that up with a few blog posts on the subject, essentially, you know, putting for their expectations that you, there, there would not be unfair and deceptive trade practices by the vendors in this space.
Speaker 2:And, and you mentioned, I guess initially there were, there were two vendors in particular that, that, um, Google and Microsoft that sort of had this concept of the, of the health record app application. But certainly during this time period that we're talking about now, there was much more than that. I remember a study by, I think it was I Q V a Institute for human data science. It said that, uh, by 2020, there were 350,000 different digital help apps in the market. And that 90,000 of them had just been released that year. So, uh, certainly, you know, the, the concept of the health app that was first contemplated in 2009, certainly came to fruition, I think during this time period. And, and that didn't go unnoticed, certainly, probably by the FTC, but, but by the media as well. And then February of 2019 in your briefing, you reference a wall street E journal article that discussed some of the practices that were, that were going on with the app developers and in particularly an app called or an app from flow health, Inc. Um, Ty, will you talk a bit about the, the broader issues raised in that wall street journal article and the situation with the flow health app?
Speaker 3:Yeah, absolutely. So that article, that you're referencing, it was an invest piece about Facebook's data collection practices and namely the sharing of personal information by various popular apps, the third parties, including Facebook, without users, uh, knowledge or consent for, for user sharing with that information and the article wasn't narrowly focused on healthcare, but it did touch on the Journal's evolving investigation into flow health. Um, and before we sort of jump into the article itself, it's worth just talking about what flow health is. So it's a company that created a period and ovulation tracking app, um, and the app itself connecting information by out women's health, including information on periods, fertility, and population at the time, the article they claimed to have about 25 million active users, it's privacy policy said that it will not share information, um, externally, unless the user likes to share that information. The investigative piece by the wall street journal found that, um, unbeknownst to users, it shared various information about administration and pregnancy planning with various third parties, including Facebook, um, and through ongoing communication with the wall street journal, we found that we found out that flow initially said in a written statement that it doesn't share externally any critical user data. And, uh, the data I does share is deep personalized to keep it private and secure. However, upon further investigation, the journal did find that, um, um, I information that is personally identifiable was shared, meaning that, um, they shared various health information, but along with that health information, they sent a unique advertising identifier, which can be used to match, um, that information to a device or a profile. So that information wasn't entirely de-identified or anonymized, if you will. And based on this finding, um, a flow held, um, spokeswoman subsequently said that the company will substantially will limit its use of extra analytics. Um, and all of this triggered an investigation by the FTC about flow health practices. I think it's also worth noting that, um, as the FTC investigated flow health, there was also a lot of, uh, pressure from the hill, namely in March, 2021, three members of Congress wrote to the FTC and encouraged it to use the breach, um, health notification rule with, uh, respect to mobile health apps. Um, when the settlements did finally come out, I think we'll talk about them momentarily. As Adam mentioned, it was not, uh, based at all on the breach rule, but instead under its authority under the FTC its authority under section five of the F PC act,
Speaker 2:Right. And I, I wanna make sure we, we touch on the, the settlement itself, but, um, before we do that, I, I wanted to make sure that I noted as well in your briefing. Uh, you referenced a 20, 20 FTC request for comment on modifying certain definitions of PHR related entity, third party service vendor, personal health records, uh, and they cited the need for this as a result of technology developments in particular, the growth and mobile health applications. I, I mentioned this in particular, at least for me, I, I see that. And I see some foreshadowing at least, uh, some, some insight into their thinking about potentially expanding the application of the, of the breach role, but before we kind of get more into their interpretation and clarification, Ty, I know you mentioned the settlement and the flow health story. Can you tell us a bit how that all did?
Speaker 3:Yeah. The sentiment hinge on, um, this big allegation that flow health promised to keep users health, data private, um, and only use it to provide, uh, the app services. And they specifically note this in their privacy policy. Uh, but you know, the, the investigation found that, um, flow health disclosed health data, uh, from millions of users to third parties for various marketing and analytic services, um, including Facebook's analytics, analytics, division, Google's analytics, division fabric, health app, flyers, and flurry, and all these were listed in the, in the settlement itself and the complaint. Um, and the information that was shared was specifically about, um, users, pregnancy, um, a physical health menstruation childbirth, and they were sent to third parties in the form of what are called app events, which is, um, when an app data is transferred to third parties for various reasons. Um, and in sharing this information, there was no limitation on how third parties could use health data itself. Um, and so if you were to read the settlement, um, they're, it's very prescriptive on what the FTC is looking for. Uh, with regard to flow health practices, they are now required as part of settlement to inform users about the purposes of data collection, um, their use and any disclosure. And they also have to, and consumers about what controls they have over their data. Um, they also have to identify, um, the parties to whom health information is being shared, the categories of health information being shared, um, and the purposes of sharing that information, including how the third party may or may not use that information. Um, and as part of all the, the flow health also has to obtain a user's affirmative express consent prior to sharing information with third parties.
Speaker 2:I think that in particular is interesting probably for the well, the reasons that one would guess, and as much as applications and application developers have had a history of the, the consumer as the product and by which we mean the, the data is really the value. And, and certainly the there's nothing that I think terribly unusual about, um, the FTC looking into when, for example, example, the, the privacy policy and other statements by the organization don't match their actual prep practices. Interestingly, though, you know, you mentioned the hill was, was pushing for the breach roll here, but they don't apply the, the breach roll, I guess, in this circumstance. But they then go on to, to in, uh, September, 2021 issue a policy statement that health apps and connected devices that collect, uh, use or use consumers health information must comply with the breach rule. Uh, but then it gets even more interesting and they start to add some additional clarifications in the policy statement. Uh, you know, Adam, I know, uh, in particular, the FTC interpretation of healthcare providers, uh, in that, uh, in that policy statement got your attention. What, what was it about that, that, that really, uh, uh, that you found was different or, uh, or really, you know, did get your attention there?
Speaker 4:Sure. So, you know, one of the challenges here is, you know, something you had mentioned earlier where, you know, there, there was maybe just a small number of PHR vendors back in 2009 when Congress enacted the high tech act. But since then we've had tens of thousands of health apps appear on the marketplace. But the big challenge is just because you're a health app doesn't mean you're a personal health record. Um, and in fact, one could argue that almost none of those tens of thousands of health apps are actually the types of personal health records that are covered in the high tech act by this breach notification role. Um, that kind of leads us to FTC who really wants to regulate these tens of thousands of health apps, but it has kind of two imperfect tools. One is section five of the FTC act. The reason that's imperfect is because it doesn't provide for financial penalty that doesn't provide for clear standards. It's really just unfair and deceptive and there's limits to what the FTC can do under that. Um, and in fact, there's been litigation over the FTC potentially pushing section five too much where there's not necessarily appropriate standards in play. Then you've got this other tool, the health breach notification rule for personal health records. And that gives much more clearly delineated authority for the FTC much better than the section five in, in certain respects. The limitation on that one, the reason that's an imperfect tool though, is it's limited to personal health records, which really never took off the way I think Congress had envisioned. And so it seemed like the FTC in this 2021 policy statement just was really trying to bridge the gap and try to make this argument that all these tens of thousands of health apps are actually PHRs personal health records, even though it's in my mind, at least not at all, what was envisioned by Congress, this idea of I'm getting mul medical records from multiple healthcare providers storing them in a app. And so one can argue that the FTC built this policy on kind of a house of cards. And one of the first ones there is they, they say the rule, the, the breach notification rule covers vendors of personal health records that contain individual identifiable health information created or received by healthcare providers. But there's this challenge that all these consumer apps, most of them don't actually have information created or received by healthcare providers and the way the FTC addressed that is they said under the definitions, cross-referenced by the rule, the developer of a health app or connected device is a quote healthcare provider because it quote Fs healthcare services or supplies. So they essentially to address this statutory limitation that they, that a PHR has to include information created received by healthcare provider. They took the position that every health app developer is a healthcare provider. Um, you know, they, they may not have doctors on staff or anything like that, but they, they viewed that the, that any of these health and wellness apps are actually considered healthcare. And therefore the developers are healthcare providers and it's worth noting a number of commissioners, um, disagree read with this and dissented. Um, and in my mind, at least certainly is a somewhat novel idea of what qualifies as a healthcare provider. We, we certainly don't think of these app developers as healthcare providers in other contexts, but the FTC to kind of fit these apps under their statutory limitations side and said, we're treating them all as healthcare providers, these app developers.
Speaker 2:It's a, it's a really interesting and challenging question. I I'm just as, almost as guilty as the FTC here in defining things, because I, we started down this path and I talked about health apps. We never really defined what we mean by health apps. And, and certainly depending on one's perspective, that can be extremely broad. You mentioned the, you know, certainly the health and wellness apps that folks are, are very familiar with in the consumer market. Uh, you know, maybe you have your Fitbit or other things that attach to it, your smart watch, your apple watch, or, or other kind of health apps. I've seen them that do as little as maybe measure my heart rate to do other things like that. Certainly not what we think of as a healthcare provider and, and not an app that probably certainly rises to the level of a software as a medical device sort of situation as well. So it's very, I think it's becoming more and more challenging to, to real, really differentiate between what we mean in, in the health app category. Uh, certainly, and, and, um, perhaps their, their in lies part of the problem to your point, the, the personal health record app that maybe we're getting there now with the new APIs, um, under the promoting interoperability rules. But, but certainly not, I think they're in the, in the way it was originally in thought out, certainly. Um, so, so difficult problem, Ty, the FTC, they, it, addition to that they discussed, um, when an app is covered by the breach role, can you walk us through their interpretation there?
Speaker 3:Yeah, absolutely. So in the policy statement itself, they noted that apps are covered if they're capable of drawing information from multiple sources, such as they're a combination of consumer inputs and PBIS, and they, um, illustratively provide two examples. The first is when an app collects information directly from consumers, and it has a technical capability to draw information through an API that syncs with, um, a consumer's fitness tracker, as an example, another example they use is, um, and it's interesting that in the second example, um, health information was they knew that health information is only needed to come from one source. So in the second example, it was a blood sugar monitoring app that collects blood sugar levels information from patients, um, this being the health information, uh, but it also links to another non-health information source such as the calendar app. And it's interesting to know that they're focusing more on capability rather than how it's used in, in practice with regard to how the information is being drawn.
Speaker 2:I, the thing that I, and I think I personally had to read this twice, because when I first read that, and it's a capable of, uh, point information from multiple sources, I immediately inserted help. Um, but it's not that it's it's any information, correct?
Speaker 3:Yeah, that's exactly it. And Adam will probably, uh, deep dive into, into how the, the definitions all coalesce, but yes, the way they, they frame it is that it doesn't necessarily have to be, um, health information. But if you look and for follow the, the breadcrumbs, it's all the regulations and definitions, there is reason to suggest that, um, it should likely be health information, but Adam, would you wanna chat more about that?
Speaker 4:Sure. So, yeah, I think, you know, we, we had this conception, at least I personally did of what a PHR personal health record was. And, and the statute talks about essentially where you pull individually identifiable health information from multiple sources and, you know, the, the app and the app maintains individual identifiable health information. And it, and it includes information pulled from multiple sources maintained on behalf of the, so my conception was always, okay, I've got my medical record from my primary care provider. I've got my medical record from my specialist. I wanna have them in one place. I bring them together on this app. And so that's, I think what most people, my, at least my view of it was, um, of what a PHR was and the, the high tech act defined a personal health record as having what's PHR, identifiable health information. And the definition in the high tech act in the statute of PHR identifiable information is that it's individually identifiable health information as defined essentially under HIPAA and includes information with respect to an individual that's provided by or on behalf of the individual. So it's essentially, uh, um, being stored for the individual that identifies the individual, um, or with respect to which there's a reasonable basis to believe that the information to be used to identify the information, uh, the individual. Um, now one of the challenges here though, is that the definition of individually identifiable health information at this statute pulls from it pulls the definition from HIPAA. And that definition is information, um, is limited to information created or received by a healthcare provider, health plan, healthcare, clearinghouse, or employer. And so that's where I think the Ft you see, seemingly in my mind, went beyond the statute in trying to apply the health breach notification rule to these health and wellness apps, for example. So, you know, they, they, they take the example of a, um, diabetes monitoring app where the consumer types in their diabetes score, and maybe the app also takes information from a calendar and that information may reside on the phone and it's unclear how it fits within the definition of individual identifiable of health information, because that information was not created or received by a healthcare provider, a health plan, a clearing house, or a employer it's just was created by the individual on their phone or received from the, the phone itself from the phone's calendar. So it seems like it kind of push things beyond what the statute actually calls for, even if you take their really broad interpretation that the app developers, a healthcare provider, and therefore anything that is received by the health by the app developer could qualify as individually identifiable health information. It still doesn't address app where the information doesn't get shared with ya developer. It just may sit on the phone. And so it seems like they, in trying to, you know, it's clear that the FTC would like to have a health app
Speaker 2:Breach notification rule rather than a PHR breach notification rule. And it seems like they essentially have, in my mind, at least gone past the statutory definition of individual identifiable health information to try to connect those and turn this into a health and wellness app breach notification rule. Uh, when I read, um, sort of, sort of your briefing that I was trying to put myself in the shoes of the FTC and how they would, let's say defend sort of their examples and, and interpretations, certainly I think they're to pull this in there forced to create that broader definition definition of healthcare provider. And I don't know that certainly on its face, most people associated healthcare provider with the app developer themselves, just as you've mentioned. And, and certainly not. When we think of it in the context of the providers within a HIPAA context, I think that's confusing in and of itself. I, I don't know like whether they were making the there's two ways I could have thought of this one is, or did think of this one is that the app that I don't really, the app is really owned by in essence, by the app developer and the users just licensing that. So maybe the putting the information in the app isn't itself giving it to the app developer, but if it doesn't leave the phone, um, you know, that's a whole nother difficult thing for me to wrap my brain around how they, how they view that or, or would defend their examples. Uh, I, I think I'm falling on your side, Adam, of, of the, uh, of maybe not being the, the best examples certainly or forced examples, uh, for the purposes of trying to squeeze something into this rule that maybe it wasn't intended for originally, Ty, they also provided some clarification on what they believe constitutes a breach of security. And it's not just what I think most immediately comes to mind, at least to, for most people, that idea of a hacker stealing data. What is the FTC saying with this clarification of definition of breach of security?
Speaker 3:Yeah. So in this statement itself, the FTP states that one health app discloses sensitive health information without the user's authorization that is breach of security, and then goes on to note that this is not limited to cybersecurity intrusions or in nefarious behavior, um, bit broadly, any unauthorized, um, disclosure without consent authorization could be a breach of security. It's interesting. If you sort of go back to the FTC breach notification rule itself, it seems to align with, with the text of the rule, which is, uh, which is where breach is defined to include, um, any of unauthorized access to covered information, including sharing with that individual's authorization, unless there is reliable evidence showing that there has not been, or could not reasonably have been unauthorized acquisition of such information. Um, there's actually more granularity in the January, 2022 blog post that followed this, um, policy statement where in the Q and a portion, they mentioned two other scenarios. One is accidentally sending users health information to the social media platform. And the other is someone accessing a company's data based without a consent. And the first scenario, they note that, um, there is likely applicability if there is disclosure for consumers, um, individually identifiable health information that is unsecured, um, without consent, then it breach likely occurred in the second scenario. They, they think that the operative question is whether there was unauthorized access or acquisition of the data. Um, and while there is a presumption of breaches can be overcome going back to the definition, if there is reliable evidence showing that there has not been, or could not reasonably have been unauthorized acquisition of such information. So to answer your question there, bring it back. A breach of security is beyond just say a cybersecurity incident. And there are various scenarios where that could be deemed a breach of security. It's interesting the way they framed it, the, the flow health settlement that could in theory fall, um, under how they define breach of security. Um, so it's unclear why the FTC chose, uh, not to use a enforcement mechanism, um, rather than section five, the FTC act, but that is how they're looking at it.
Speaker 2:Yes, I, I, and that's what really caught me. I was like, okay, if that's really the definition, then why didn't we apply it in the, in the flow case is particularly when there's political pressure to do so perhaps, and, and maybe it's because they felt that they needed to do these clarifications in order to justify that. I, I, you know, I can only speculate, uh, as to, as to their thinking there, but it seems like it would've been the certainly an opportunity. So I I'll, I'll throw this out to either of both of you and what is the FTC attempting to do with its policy statement. And is this a case of maybe the creators of new business models and technology outrun, the regulators, and now they're trying to play catch. And I, I think Adam, you mentioned this, you know, trying to they, what they really want a different rule, but this is the only rule they have. So let's make it fit sort of situation.
Speaker 4:I think that's right. I think it's not a matter of them playing regular catch up. It's a matter of them, not necessarily being thrilled with the statute that they have and trying to come up with whatever jujitsu they can to apply the, the existing statute to these new models. So, you know, I think with respect to, you know, section five, they've always been pretty on top of new and emerging technologies. So, you know, it's not a matter of regulatory catch in that respect. It's just, you know, trying to fit a square peg into a round hole right now, because that's the only choice they have in their, in their, in their mind. I suspect.
Speaker 2:So Ty, you mentioned that they reinforced their interpretation, uh, in January, 2022 with a, a blog post. And I, I don't know if there's anything additionally you wanted add about that certainly feel free, but you know, again, either both of you given the, this new FTC in interpretation, what advice do you give to, let's say a health and wellness app developer after Adam, you convince them that they're a, now a healthcare provider. Um, if they have a breach, uh, do, do you report, uh,
Speaker 4:I'm not gonna try to convince anyone that they're a health care provider<laugh>, um, you know, I, I think that Organizations ha can decide, you know, do they wanna tackle this now? Do they wanna do a wait and see approach? Do, does anyone out there wanna take the lead and challenge this statement? Um, and do they have standing to, as that this statement is inconsistent with the statute itself? And so, you know, there's the question of, do you do anything now or do you sit tight? Um, and if you sit tight and then there is a breach in a few years, uh, do you, you know, play the teacher's pet and just follow the guidance and treat yourself as a PHR vendor, even though there might be an argument otherwise, um, or do you, um, go ahead and not report taking the position maybe internally that you are not a PHR vendor, that this guidance does not have the force of law and under the statute, the, and the regulation text itself, it's not applicable. And if the FTC ever finds out about this and challenges you that you're willing to maybe go to court to defend it. So, you know, I, I think entities, you know, have choices ahead of them as to whether they wanna take action now, or they wanna wait and state breach notification laws also come into play here, because if you are gonna have to report this breach anyway, under state breach notification laws, then that may significantly influence your decision as to whether you are also gonna report to the FTC where you, you may be reporting the individuals anyway. So it's just a matter, do we add another regulator to the mix or is the incident one where it would not be reportable under any state laws? And so it just becomes down to whether you wanna follow the FTC law or not. So, you know, factors like that may way heavily in your decision making process,
Speaker 3:We do somewhat empathize with the FTV. I think we are all seeing an avalanche of, of consumer health and wellness technologies, tools, apps, you name it. Um, and I think you, you gave us interesting stab at the beginning, John, of the number that, um, we've seen recently and given that backdrop, and also given, you know, the various interoperability information blocking rules, both from the O C and CMS, um, there is, you know, this encouragement to use more standardized APIs, such as fire to exchange health data, but there isn't necessarily, um, any new privacy restrictions outside the scope of HIPAA that apply. And I, I think it's, it's fair to say that a lot of this is because the government is relying on the FTCs authority for oversight enforcement, as Adam pointed out, the FTC only has two imperfect mechanisms. So there's open space for a solution. And I think they're, they're working with what they have.
Speaker 2:Yeah, I think, I think it's ironic, maybe not the right word, but we're, we seem to be on the cusp of, uh, of applications really becoming what was anticipated, the, the PHR type of application, where we have APIs available, where you can pull in your health records from your different physicians, as well as your, your, uh, health insurance carrier into an app. And it seems like just when we're, when that's that policy objective, if you will, to a certain degree or, or, uh, goal is being achieved, we now have this broadening of the FTC role to include, uh, these health and wellness applications that are to Adam's point weren't originally contemplated. I don't think so. It's a, it's an interesting time, certainly, uh, for them to, to sort of broaden their rule. I, I was thinking too, Adam, you know, you mentioned in the examples, the case of the app where the data is only residing on the application itself or the device where the application is, and, and one would assume that device is probably totally within the control of the user. And if there's a breach at that level, a, I don't know that the, the app developer would even be aware of it, but let's assume that they are, do I have to report a breach on a device of a user where that data was only on that app. I, you know, it's, who knows it's, uh, becoming a little, it gets a little more complex, any final thoughts? Uh, I guess that that's all I had any final thoughts that Ty Adam, that, that you think important for the listeners to, to hear
Speaker 4:I'll echo ties point. I mean, I very, I do empathize with, you know, the FTC, the FTC is trying to use what it's got to regulate, um, in an area where I don't think there's much question that, you know, especially with the increase in inability, there's a need to, you know, have safeguards here. You know, part of me says, well, Congress needs to really provide a statutory authority for the FCC to do what it needs to do here. The other half of me says, I'm not sure I would wanna see what, what the result would be<laugh>. Um, but, you know, I, I think, you know, there, there's no question we have a new problem. We just don't necessarily have the right tools to address it right now.
Speaker 2:Tie any thoughts?
Speaker 3:No, I, well, I will say, I feel like all of this has the backdrop of, of healthcare, at least consumer health. It's getting closer to home where there, there are some finite examples we talked about, um, in this podcast, but I mean, the are so many health and wellness apps that range from physical wellness, whether it's women's health, fitness, nutrition, there's also mental, emotional wellness such as like mental and behavioral health apps. Um, and then if you think about healthcare as a spectrum, I think we're sort of getting as, as we evolve in healthcare, I think there's that, um, seeing care in, in acute or institutional settings, I think that will obviously continue to exist, but there is more of, of health or preventative health happening, you know, with my phone or at my home, by myself, rather than with an institution or with a provider. And with that spec driven with it sort of getting closer to home. I think it, it's only reasonable to expect more and more apps and more and more companies, um, trying to take advantage of this market.
Speaker 2:Yeah, I, I think, and certainly it, it seems as if the public generally has an expectation that, uh, in particular, you know, their person, no health information is gonna be protected and that there's, uh, certain security around that. And, and that they'll have an opportunity to weigh in if, and when that information is shared, we see that oftentimes with the, uh, with the general public thinking that the hippo regulations for example, are apply to far more organizations than they actually do. And I think that, you know, the there's a desire by the, uh, policy well has been for over a decade now, you know, kind of a policy decision at the federal level to encourage the electronic exchange of, of data for purposes of improving healthcare decision making, as well as potentially lowering their cost associated with, with healthcare. And, and one can argue whether either those policy objectives are, will be achieved, but nevertheless, we've done put a lot of things in place and made a lot of investment to encourage the sharing of, of digital health and information. And, and, uh, the APIs that we mentioned are, are the latest trend in that. And I think that, that, uh, that this, all of this, isn't a bit in a response to that. And, and it'll be interesting because I think that, um, in order for the adoption to continue, and there's been some discussion about whether of the adoption of health and wellness apps, digital health apps is slowing down. Uh there's I think one study that said that the main reason was concerns about the, the, um, confidentiality, integrity and availability of data. It's typical security type of stuff that, um, that if the government wants to continue promoting the use of, of an exchange of digital health information, they're gonna need to have appropriate regulation in place. And, and, uh, we'll see how that all plays out. That's all I had. And unless you guys have, uh, any other thoughts on, on, uh, this we'll, we'll call it a day. I really am grateful to you, both Ty and Adam for taking the time to talk with me today and, and with the audience here at a H L a about this important issue and, and obviously very current topic as we, uh, as we see the, the APIs going into place, the continuing use of this type of health application.
Speaker 4:Thank you, John. Thank you, HLA for having me.
Speaker 3:Yeah. Thank you, John and HLA for, for having us. And it was, it was great to be part of the journey.
Speaker 1:Thank you for listening. If you enjoy this episode, be sure to subscribe to a L a speaking of health law, wherever you get your podcasts to learn more about ALA and the educational resources available to the health law community, visit American health law.org.