Scary acronyms

Uploaded on


More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • FDA does not intend to regulate “mobile apps that are solely used to log, record, track, evaluate, or make decisions or suggestions related to developing or maintaining general health and wellness.”  Examples of health and wellness apps are provided in the guidance, and include dietary tracking logs, appointment reminders, dietary suggestions based on a calorie counter, posture suggestions, exercise suggestions, etc. In contrast, a mobile medical app is one that is intended for “curing, treating, seeking treatment for, mitigating, or diagnosing a specific disease, disorder, patient state, or any specific, identifiable health condition.” FDA intends to place most stringent requirements on devices that pose the most risk; general controls only for those that pose minimum risk to morbidity/mortality


  • 1. Scary Acronyms – A Review of Regulatory and Legal Issues Core to Health IT Deven McGraw, JD, MPH, LLM Director, Health Privacy Project September 29, 2013
  • 2. Health Privacy Project at CDT  Privacy = enabler to flows of data that have the potential to improve individual, public and population health  Aim is to build public trust in these data flows, through balanced & workable protections, as they are essential to patient engagement, health reform and building a “learning health care system.”  In other words, let’s make the acronyms not so scary
  • 3. Acronyms to Know  HIPAA  HITECH  FTC  FDA  And a few more for good measure: ECPA, SCA, and FCC, CMIA (California)
  • 4. HIPAA  Health Insurance Portability and Accountability Act  Establishes privacy and security requirements for identifiable health information (otherwise known as “protected health information” or PHI) collected, used and disclosed by “covered entities” and their “business associates”  Does not cover all heath data  You do not trigger HIPAA coverage merely by accepting PHI from a covered entity or business associate.
  • 5. HIPAA  Covered entities: providers, health plans, health care clearinghouses  All defined in the regulations (45 Code of Federal Regulations (CFR) Part 164)  Business associate: an entity that “creates, receives, maintains or transmits” PHI in fulfilling certain functions or activities on behalf of a covered entity. (45 CFR 160.103).  Recent final regulations clarified who is (and who is not) a business associate – cloud storage providers are; “mere conduits” are not. Entities must have BAAs (business associate agreements).  See CDT FAQ for more info:
  • 6. HIPAA  If you are covered by HIPAA:  Privacy Rule sets forth rules regarding access, use and disclosure of PHI (paper & electronic); Security Rule sets forth detailed safeguards regarding electronic PHI (doesn’t apply to paper)  Privacy Rule:  Permits some routine uses and disclosures without the need to obtain patient consent; requires notification in event of breach  Requires patient authorization for other uses & disclosures  Security Rule  Establishes administrative, physical, technical and organizational safeguards  Some are required, others are “addressable” implementation specs
  • 7. HITECH  Health Information Technology for Economic and Clinical Health Act of 2009 (part of the American Recovery and Reinvestment Act (ARRA))  Authorized tax incentives for purchase and “meaningful use” of Certified EHR Technology (CEHRT) by certain groups of providers and hospitals  Also included changes to HIPAA Privacy Rules (recently finalized in the “Omnibus Rule”)  Program began (Stage 1) in 2011; meaningful use objectives more robust in Stage 2 (begins for early adopters in 2014)
  • 8. HITECH Opportunities  Helping providers and hospitals meet meaningful use “objectives” and quality metrics  Must use CEHRT (new certification requirements go into effect in 2014)  Must use required standards  In Stage 2, meaningful users must make available – and get a percentage of their patients to use – portals enabling patients to view, download and transmit their health information  HIPAA new Omnibus Rule also clarified patient’s right to electronic copies of their health information
  • 9. Omnibus Rule “Wins” for Patients  Ordinarily, Security Rule applies to all transmissions of ePHI; this has been an obstacle to use of some digital technology to communicate with patients  BUT recent omnibus rule suggests patient can choose to receive communications (to the patient) in a form/format that works for them, even if they are not secure  Provider must provide “light” warning (this is unsecure – are you sure?)  Arguably also relevant to other communications (not just requests for copies of records)
  • 10. Omnibus Rule “Wins” for Patients  Patients also have the right to have information directly transmitted to the recipient of their choice.  Choice must be “clear, conspicuous and specific;” per regulation, just be in writing and signed (can be electronic), and “clearly identify the designated person and where to send a copy of the [PHI]”  Covered entities must implement “reasonable safeguards” to protect information that is disclosed pursuant to this provision. (Question: not clear if patient can specify unsecure e-mail for information transmitted to a 3d party at the patient’s request)
  • 11. FTC  Federal Trade Commission  Under the Federal Trade Commission Act (FTCA), have the power to take action against unfair and deceptive trade practices by entities in commerce (not nonprofits)  Also enforce breach notification requirements for “personal health records” (and entities that offer services through PHRs) enacted under HITECH  Breach standard – acquisition of identifiable information without the individual’s authorization.  Deceptive = breaking commitments to consumers re: data privacy. Unfair = ?
  • 12. FTC and Privacy  FTC final report (March 2012-  Articulated privacy framework based on fair information practices; contextual approach to consent  Called on Congress to enact baseline privacy legislation  Praised ongoing efforts on Do-Not-Track and endorsed industry codes of conduct  Endorsed role for U.S. in achieving harmonization of U.S.-global data privacy policies  Workshop on “Internet of Things” on November 19. One focus is connected self/health
  • 13. Additional Resources re: Privacy  CDT and Future of Privacy Forum Best Practices for Mobile App Developers: Practices-Mobile-App-Developers.pdf  Markle Common Framework for Networked Personal Health Information (for connecting consumers): framework/connecting-consumers
  • 14. FDA  Food and Drug Administration  Authorized by Congress to regulate medical devices  Software that acts as a device is subject to medical device regulation  Degree of regulation depends on the risk classification for the device (ranging from general controls in Class I; general + special controls in Class II; to premarket approval in Class III).  Relevant to manufacturers of software that qualifies as a medical device.
  • 15. FDA Regulation of Apps, EHRs  FDA takes the position that EHRs and other medical software applications (apps) are medical devices, subject to FDA regulatory authority  Issued & sought public comment on initial draft guidance for “mobile medical apps” (July 2011)  Seeking to regulate apps that more clearly perform the role of a medical device; does not include apps designed to be used for general health & wellness (like a fitness tracking app)  Distinction not that clear in the draft guidance
  • 16. FDA Regulation of Apps Controversial  Guidance generated some controversy.  Congress (in the FDA Safety and Innovation Act of 2012) called for federal advisory committee to examine issue, make recommendations  Health IT Policy Committee recently recommended a risk- based framework for regulating medical software ( endationsDraft030913_v2.pdf) (finalized in early September 2013, although initial recommendations were vetted in August 2013)
  • 17. Final Guidance Issued 9/23  uidance/GuidanceDocuments/UCM263366.pdf  FDA is focusing only on apps that are medical devices and “whose functionality could pose a risk to a patient’s safety if the mobile app were not to function as intended.”  Focus is on how app is intended to be used  Will look at all evidence on intended use  Platform agnostic  Guidance does not establish “legally enforceable responsibilities” but instead describes FDA’s current thinking on a topic.
  • 18. Final Guidance Issued 9/23  More clarity on where FDA will focus oversight.  FDA’s focus is on safety, not privacy  Medical apps that:  Are extensions of one or more medical devices (such as those that display device data);  Transform a mobile platform into a regulated device; or  Perform “patient-specific” analysis or provide “patient-specific” diagnosis or treatment recommendations Will be subject to device regulation.
  • 19. Final Guidance Issued 9/23  Guidance also lists types of apps for which FDA intends to exercise “enforcement discretion” (no enforcement at this time):  Apps that provide or facilitate supplemental clinical care, by coaching or prompting, to help patients manage their health in a daily environment.  Apps that provide patients with simple tools to organize and track their health information.  Mobile apps that provide easy access to information on a patient’s health conditions or treatments  Apps specifically marketed to help patients document, show or communicate to providers potential medical conditions.  Apps that perform simple calculations routinely used in clinical practice.  Apps that enable individuals to interact with PHR or EHR systems.  More examples provided in guidance.
  • 20. ECPA (specifically, SCA)  Electronic Communications Privacy Act, specifically the provisions of the Stored Communications Act.  Prohibits entities providing electronic communication services or remote computing services to the public from divulging the contents of any communications carried or stored by the service, absent consent.  Remote computing services is defined as providing the public with storage or processing services by means of an electronic communications system.
  • 21. ECPA/SCA limits  Protections can be waived by consent – consent provided by agreeing to terms of service may be adequate.  Protections apply only if the provider of the storage/processing services is not authorized to access the contents of the communications for purposes of providing any other services  So if information analyzed for purposes of targeting advertisements, or performing analytics, that service may fall outside of ECPA’s coverage.
  • 22. FCC  Federal Communications Commission  Rules apply to communications carriers (for example, telephones, wireless devices, cable subscribers) and prohibit the sharing of certain information about customers  vacy.pdf
  • 23. CMIA  State laws may also be a concern!  For example, the Confidentiality of Medical Information Act, the primary health information privacy law in California  Initially like HIPAA covered medical professionals and facilities – but legislature has recently expanded coverage  First expanded to cover “any business organized for the primary purpose of maintaining medical information” in order to make it available to an individual or a health care provider.  This year expanded further to cover software and medical apps (AB 658 was signed by the Governor earlier this month).
  • 24. Not too scary at all! Questions? Deven McGraw 202-637-9800 x115