{"id":2112,"date":"2012-02-08T06:57:58","date_gmt":"2012-02-08T06:57:58","guid":{"rendered":"https:\/\/www.empowerbpo.com\/blog\/?p=2112"},"modified":"2023-03-01T17:18:51","modified_gmt":"2023-03-01T17:18:51","slug":"mhealth-challenges-around-privacy-and-hipaa","status":"publish","type":"post","link":"https:\/\/www.empowerelearning.com\/blog\/mhealth-challenges-around-privacy-and-hipaa\/","title":{"rendered":"mHealth Challenges Around Privacy and HIPAA"},"content":{"rendered":"<p>Emerging technologies are beginning to blur the traditional, clear distinctions around privacy and health data \u2013 this is especially true with mobile health (mHealth) solutions. Those involved in regulatory circles are trying to develop a cohesive framework that will encourage innovation, while at the same time protect consumer privacy.<\/p>\n<p><b>A little background\u2026<\/b><br \/>\nGeneral consumer privacy around Personally Identifiable Information (PII) is addressed by a set of rules that affect everyone. At the federal level, PII is defined in certain standards (NIST SP 800-122), and protects confidentiality of PII in information systems from inappropriate access and disclosure. Some types of personal identification numbers, such as social security numbers or bank account numbers, are particularly sensitive (can be used to commit identity theft and steal money from bank accounts). Best-practices, particularly using Internet banking products, focus on protecting this kind of information.<\/p>\n<p>Health information has an additional layer of regulation \u2013\u00a0<a href=\"https:\/\/www.empowerelearning.com\/online-hipaa-training\/\"><b>HIPAA<\/b><\/a>\u00a0protects Personal Health Information (PHI) from being disclosed without a patient\u2019s consent. HIPAA privacy and security was initially defined in the Health Insurance Portability and Accountability Act of 1996, and revised in the 2009 HITECH portion of ARRA (the same legislation that enacted the federal EHR Incentive Program, or \u201cmeaningful use\u201d).<\/p>\n<p>HIPAA defines \u201ccovered entities\u201d (CEs) \u2013 health care providers (including doctors, hospitals and laboratories), insurers, and certain kinds of intermediaries. It also covers \u201cbusiness associates,\u201d who manage PHI on behalf of CEs, and requires that Business Associate Agreements be in place to codify that the PHI is managed in a way that maintains security and privacy.<\/p>\n<p>Consumer-generated health information vs. PHI<br \/>\nWe are seeing an explosion of consumer-generated health data on the Internet, as well as in the mobile app space. A myriad of sites offer tools to help individuals track various health-related statistics, and perhaps share them socially with their friends. Things like pedometers or FitBit devices help track healthy walking and activity. Self-entered calorie counters help manage eating habits. In fact, a whole Quantified Self movement is emerging where self-tracking tools are believed to be an important feedback loop that helps enthusiasts improve their health status.<\/p>\n<p>Such consumer-originated data, even though it is \u201chealth data,\u201d is not PHI as covered by HIPAA. No HIPAA-defined CE holds this data. It is PII, and is covered by general privacy rules about that, but it is not PHI.<\/p>\n<p>Now when that health data is shared with a CE \u2013 with a doctor, hospital, insurance plan, or other HIPAA-defined CE \u2013 then it becomes PHI. From the consumer side, the self-created data can be shred with anyone that individual wants \u2013 even posted on Facebook, if desired. However, the data that is shared with the doctor is PHI, and the doctor cannot share it with anyone else without the patient\u2019s consent.<\/p>\n<p>This kind of distinction makes the security requirements around data sharing a little asymmetrical. If a consumer wishes to disclose data to someone else, it can be done in a less-secured way \u2013 a regular email (which is not secure enough to meet HIPAA requirements) can state \u201cmy blood sugar this morning was 103!\u201d and can be sent to a friend, or whomever. Sending such an email to one\u2019s doctor, however, is a little more dicey \u2013 the doctor is a HIPAA-defined CE, and receipt of such an email would need to be protected once it is received (it becomes PHI on the doctor\u2019s end). Better to use a secure way, such as a secure web-mail portal requiring login and password, for sending that kind of information \u2013 that way the doctor won\u2019t need to secure the received message manually and destroy the original unsecured message.<\/p>\n<p>Communication from a doctor to a patient is PHI, given that the context of the communication implies a therapeutic relationship \u2013 it thus needs to be secured. If a doctor wants to tell a patient \u201cyour blood sugar this morning was 103,\u201d then that message needs to be protected in a way consistent with HIPAA security (a secure message, not an unencrypted email).<\/p>\n<p>Where it gets fuzzy<br \/>\nA number of mHealth applications are emerging that bridge the gap between consumer-generated simple health data and PHI. For example, let\u2019s consider a potential application that prompts people on maintenance medications dose-taking \u2013 it will create an alert that says \u201ctake your medication.\u201d For the sake of example, let\u2019s say that this smartphone app also collects some information from the patient \u2013 questions are asked like \u201cdid you take your med?\u201d and \u201cif not, why not?\u201d. Or even, \u201cwould you like to see some information on alternatives?\u201d (and render ads if answered \u201cyes\u201d) \u2013 or maybe not even ask for permission and offer ads for alternatives anyway.<\/p>\n<p>If such a postulated app were generally available directly to the consumer, downloaded by the consumer, and used to collect one\u2019s own health data, then it would simply be consumer-based health data \u2013 even if the data is associated with a specific cell phone number (not technically PII).<\/p>\n<p>However, if that same app were \u201cprescribed\u201d by a HIPAA-defined CE (such as a doctor, an insurance company, or an independent pharmacy drugstore), then a therapeutic relationship is implied. If the app were designed to send that data back to its originator \u2013 back to the insurance company, or the doctor, or the retail pharmacy \u2013 then the sent-back data is PHI, and needs to be protected at HIPAA-security levels. Further, the patient needs to be able to opt-in about whether the data can\/should be sent back to the CE \u2013 keeping the data oneself maintains it as simple \u201cconsumer health data\u201d but sending it back to a CE makes it PHI.<\/p>\n<p>Conclusions<br \/>\nEmerging technology dances the line between consumer health data and PHI. The HIPAA implications of such technology should not be feared \u2013 only taken into account when designing such systems.<\/p>\n<p>When the distinction between consumer health data and PHI is clear, then the levels of security and permission that are appropriate can be built into these new products. Innovation in the mHealth space should be encouraged \u2013 after all, dramatic advances in the health of the country can emerge from such new technology. It needs to be done right, however. This is an area where early consultation around HIPAA and data privacy and security would certainly be worthwhile. We will likely see the emergence of such consultative services more and more as this new field of technology evolves.<\/p>\n<p><a href=\"https:\/\/www.practicefusion.com\/blog\/mhealth-challenges-around-privacy-and-hipaa\/\" rel=\"nofollow noopener\" target=\"_blank\">Read more here.<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Emerging technologies are beginning to blur the traditional, clear distinctions around privacy and health data \u2013 this is especially true with mobile health (mHealth) solutions. Those involved in regulatory circles are trying to develop a cohesive framework that will encourage innovation, while at the same time protect consumer privacy. A little background\u2026 General consumer privacy [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[77,27,75],"class_list":["post-2112","post","type-post","status-publish","format-standard","hentry","category-hipaa","tag-hipaa","tag-hipaa-compliance","tag-hipaa-law"],"_links":{"self":[{"href":"https:\/\/www.empowerelearning.com\/blog\/wp-json\/wp\/v2\/posts\/2112","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.empowerelearning.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.empowerelearning.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.empowerelearning.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.empowerelearning.com\/blog\/wp-json\/wp\/v2\/comments?post=2112"}],"version-history":[{"count":0,"href":"https:\/\/www.empowerelearning.com\/blog\/wp-json\/wp\/v2\/posts\/2112\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.empowerelearning.com\/blog\/wp-json\/wp\/v2\/media?parent=2112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.empowerelearning.com\/blog\/wp-json\/wp\/v2\/categories?post=2112"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.empowerelearning.com\/blog\/wp-json\/wp\/v2\/tags?post=2112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}