by Grant Elliott, Founder & CEO, Ostendio
By simply following the media hype around the recent September 23rd implementation deadline, you could be forgiven for thinking that the final omnibus rule is bad news for mobile health application developers. To recap, the final omnibus rule came into effect on March 23, 2013 but "business associates" were given six months from that date to become compliant with the new requirements.
Among other things, the final omnibus rule expanded federal liability for the HIPAA privacy, security and breach notification rules to now include business associates. Before this, business associates were liable only to the covered entity they were doing business with and only for whatever terms were included within the business associates agreement (BAA) they signed. While the covered entity was required to include standard terms within the BAA, in theory if no BAA was ever executed the business associate had no legal obligation whatsoever. Which might have been good for the business associate, but no so good for the covered entity or the end user.
But now whether a BAA is in place or not, if the supplier is operating as a business associate then the Office of Civil Rights (OCR) has the authority to hold them federally liable for all aspects of the security rule, the privacy rule and the breach notification rule. That liability can be significant with potential fines reaching up to $1.5 million per breach, where a business associate is found at fault.
So where is the good news? There are two areas that offer encouragement to mobile health application developers.
The first is within the final omnibus rule itself and related to the breach notification rule where business associates now have greater flexibility to decide what is reasonably considered to be a breach. For example, previously if a laptop containing personal health information (PHI) was lost or stolen the covered entity or the business associate would have to report this event whether the data was accessed or not. But now the final rule allows the BA to make a reasonable determination based on risk so, if the laptop was securely encrypted or the data could be remotely wiped before access could be obtained, then it could be reasonably determined that no breach had occurred. In such a situation the BA would not be required to report the incident, avoiding unnecessary cost and potential damage to their reputation.
The second advantage has received much less press and this is because the implications are not so clear within the language of the final rule itself, rather it is made clearer in supporting documentation provided by the Office of Civil Rights (OCR). The advantage is related to the increased data rights given to patients , specifically their rights to be informed, obtain copies of, and request corrections be made to their information. Associated with this right is the ability to request their data be copied to a data repository such as a Personal Health Record (PHR). If this PHR is managed by the covered entity then the data still falls under the rules of HIPAA. But if it is a private PHR, such as Microsoft HealthVault, and the operator is not acting on behalf of the covered entity, then once the data is transferred to this repository it is no longer covered by HIPAA. Instead, it is governed by whatever privacy policy the user consented to when signing up for the PHR.
This is not necessarily clear within the final rule itself but is clarified in a separate document issued by the OCR called “Personal Health Records and the HIPAA Privacy Rule" (PDF), which states: “The Privacy Rule does not apply to PHRs that are not offered by health plans or health care providers” and that “These PHRs are governed by the privacy policies and practices of the entities offering or administering the PHRs, as well as by any other applicable laws.”
So how can this help mobile health application developers?
Essentially a PHR is an application that stores and manages patient data. If a privately managed PHR can be exempted from HIPAA after obtaining the appropriate end user consent, then logically so can any other application operated independently of a covered entity regardless of purpose. Mobile health providers who develop and market independent mobile health applications and services to end users, are not business associates, and can therefore store sensitive personal health information on behalf of a that user without the need to be compliant with HIPAA. In fact, even if data is directly entered by a covered entity such as a health plan or a health care provider the OCR document still exempts the application provider from any obligation under HIPAA once data resides in the private application, assuming the appropriate end user consent has been obtained.
This is not an isolated change by OCR and it is in line with Department of Health and Human Services’ objective to increase the level of control users maintain over their own data. The Blue Button initiative, coordinated by HHS, has been set up with the express objective of empowering users to be able to share their data electronically with whoever they want. The idea is that by making it easier for people to access, share and use their health information in a secure, structured way, they will be empowered to take a more active role in their care, and serve as an equal member of their care team.
More than 500 organizations have already pledged to support Blue Button, according to Adam Dole, Presidential Innovation Fellow at the Department of Health and Human Services.
To provide successful solutions mobile health application developers still need to ensure they build safe and secure products, but in many ways the final omnibus rule, far from being something they should fear, may actually give them greater flexibility and control to develop more innovative solutions unencumbered by the administrative burdens of HIPAA.