The aim of the recent Getting Back to Basics post was to re-establish the key fundamentals of how HIPAA operates. To summarize in a sentence, HIPAA applies to certain defined entities working or interacting with healthcare information related to an individual. It should absolutely be recognized that that statement is a gross over simplification of HIPAA, but should be sufficient to provide a grounding for this next step in the discussion of HIPAA’s scope.
Foundational Question for Digital Health
With the current reach of HIPAA as the grounding, what is the impact for digital health? The answer to that question very much depends on the intended use and commercialization approach for the digital health tool. Typically, the first question to ask of a digital health solution is: who is the targeted user base (which often translates to who will pay for the digital health tool). The answer to that question frequently follows one of two paths: (i) direct to consumer or (ii) to healthcare organizations before getting to end users. The answer very much influences the application of HIPAA to the solution.
Direct to Consumer
When the answer is direct to consumer, the developer usually means that the solution will be made available (for free or some charge) in the general consumer market. Numerous examples of digital health mobile apps can be found in either the Apple App Store and/or the Google Play Store in that regard, but may include nutrition tracking, femtech solutions, and many others. On the physical technology side, any wearable like an Apple Watch, FitBit, Garmin, or others are devices that clearly generate healthcare information and are available on the open market.
In each each instance, the tool is sold without any connection to a healthcare care delivery organization. The concept is that individuals can track their own health information to act on the results independently or provide to their clinician (at least the hyped or suggested use). Emphasizing the direct exclusion of traditional healthcare entities from the chain is important when thinking about the application of HIPAA. As was covered in the Back to Basics post, HIPAA only applies to covered entities, business associates, and subcontracts of business associates. In the direct to consumer market, the developer of the digital health tool does not fall into any of those categories. Instead, the digital health developer is similar to any general developer of a consumer tool. Given that assessment, HIPAA does not apply, which further means that none of the privacy or security rights and protections set out in HIPAA will protect the new category of health data being created in the tools. The absence of HIPAA protections is often surprising as many assume that all health data are protected. In this case, the traditional saying about the word “assume” certainly applies.
Through Healthcare Organizations
Does the outcome change when a digital health tool is offered through a healthcare organization at the top level? Yes. Laying out the process for this scenario, a digital health developer will usually enter into an agreement with, for example, a health system of physician practice. The care delivery organization now has the digital health tool as another option in its toolbox to implement with patients, which could translate to having patients sign up for a particular application and have the resulting data fed to the clinician.
The relationships created in the scenario of a digital health tool contracting directly with a care delivery organization mean that a service is being provided for and on behalf of the care delivery organization. That phrasing was very deliberate because it is mimics the definition of a business association, which is the role of the digital health developer in this context. As a business associate, the digital health developer now has HIPAA obligations, which means the data flowing through the digital health tool’s ecosystem are protected by HIPAA.
Can It Be Both?
Can a digital health developer pursue both paths? Yes, that is certainly an option. In that instance, the digital health developer becomes a hybrid organization. Hybrid organizations must recognize that HIPAA applies to some of the data collected or interacted with (the data relating to the care delivery organization) and other data are not subject to HIPAA (the direct to consumer side). Implementing a hybrid approach can potentially be burdensome on the digital health developer as it creates to distinct flows within the company and the need to carefully track which data are going where. From that perspective, some companies may choose to apply HIPAA protections and obligations to all data collected solely for purposes of avoiding unintentional errors and violations. However, that approach is not mandated and subject to the preferences of each organization.
What Does HIPAA Compliance Require?
For digital health developers subject to HIPAA, what does that actually mean? Most simply, it means that digital health companies need to implement the full Security Rule, follow portions of the Privacy Rule, have breach notification procedures, and ensure that a Business Associate Agreement is in place before working with the protected health information.
Implementing the full Security Rule translates to first doing a risk analysis and then developing the policies and procedures identified in the HIPAA regulations. For many in digital health, the policies needed for HIPAA amount to putting in writing many of the procedures that would be followed anyway. Having the written policies required by HIPAA being the only change needed is a result of HIPAA not imposing what would be considered current best security practices. HIPAA establishes the basis for building stronger protections as it is a foundation. If a digital health tool is serious about security from the start, then demonstrating HIPAA compliance should be relatively easy.
On the privacy side, much of the HIPAA Privacy Rule really applies indirectly as obligations are passed down through each covered entity that the digital health developer contracts with. However, it is still viable and possible to proactively follow what the limitations on uses and disclosures as well as individual rights that are set out. While proactive compliance is possible, it should be noted that any parameters imposed through a Business Associate Agreement will influence what happens in reality.
The overall impact of HIPAA, therefore, should be seen as an overlay to good operations within a digital health company anyway. HIPAA should not be seen as a new burden, but something that is already addressed by a considerate and thoughtful approach to interacting with healthcare related information. Optimistically, a digital health company would be respecting an individual’s interests and not seeking to take inappropriate advantage of sensitive information to which it is entrusted. It is fully acknowledged that that sentiment is very optimistic.
What Happens in the Absence of HIPAA?
When HIPAA does not apply, protection of consumer healthcare data is a lot murkier. Many states (think California, Virginia, and New York as examples) are enacting broad based privacy laws that try to restore some balance and give individuals more protections. However, the state laws do not necessarily apply to every company either. Many of the state laws include conditions to be met before the protections of the law will kick in, which conditions can take the form of revenue minimums and/or data collection minimums. That can mean many companies will still fly under the radar of the privacy protections from state laws. The diversity of the state laws make it difficult to give a full assessment easily, but the bottom line is that assuming state law will help can be misplaced.
With all of the potential avenues that can be followed when it comes healthcare data created through digital health, asking questions and reviewing the specific application of a tool is important. Never assume that data will automatically be protected. It is a complicated world and that situation will not change any time soon.
This article was originally published on The Pulse blog and is republished here with permission.