The mHIMSS Policy Group presented our “Summary of Federal Policies and Mobile Applications" just before annual conference this year. While HIMSS has a version, most of it is copy/pasted below. The awesome summary table can be opened  here.


February 2012

Dear Reader –

The mHIMSS Policy and Regulatory Implications Workgroup is pleased to present this summarization of mHealth related federal regulations and policies. For those developing a mobile policy, summaries regarding OCR’s HIPAA and CMS/ONC/NIST’s Meaningful Use will be particularly insightful. Additionally, this guide covers information related to developers and manufacturers, and includes insights from the FTC, FCC, and FDA’s Mobile Medical App Guidelines.

The team, chaired by Jessica Jacobs, includes the original work of Wendelyn Bradley, Nick Falcone, Rebecca Kennis, Lee Kim, Michael Kuriland, Patricia MacTaggart, and Daisy Wong.

  • Wendelyn Bradley, BSN/MA, MS Medical Informatics -- Scripps Green-Scripps Health-Administrative Clinical Project Manager. A Scripps employee for 14 years, for the past 10 she has guided clinical software implementation projects. Currently she leads the Perioperative Optimization project and system-wide clinical system roll out.
  • Nick Falcone, CISSP -- Security Operations Engineer with the Children’s Hospital of Philadelphia, is responsible for HIPAA Security Rule compliance, risk assessment, third party management, and policy and procedure.
  • Jessica Jacobs, MHSA, CPHIMS -- Oak Ridge Institute for Science and Education Fellow stationed at the Food and Drug Administration’s Center for Drug Evaluation and Research. [1] She helped stand up the Federal mHealth Collaborative and currently leads FedTel’s “Technology, Innovations, and Standards” workgroup.
  • Rebecca Kennis, CPHIMS -- System Analyst at UHS Hospitals in Binghamton, NY. She is responsible for managing the development and maintenance of mobile device applications, clinical decision support and Meaningful Use initiatives.
  • Lee Kim, BS, JD -- Attorney at Tucker Arensberg, PC. She is an intellectual property and healthcare information technology attorney and a board member of Western Pennsylvania HIMSS. She previously worked in the field of heath information technology.
  • Michael Kurliand, RN MS -- IS Strategy Consultant at the Children's Hospital of Philadelphia. Member of an IS team under the CIO that is responsible for the overall strategic assessment and planning process as well as industry and trend analysis and implementation development.
  • Patricia MacTaggart, MBA, MMA -- George Washington University Lead Research Scientist and Lecturer at the Department of Health Policy/School of Public Health and Health Services and Adjunct Associate Professor, Health Policy & Management, UNC-Chapel Hill. She is a member of HIMSS Public Policy Committee and advises Security and Privacy track students for ONC’s HITECH funded University Based Training Graduate Certificate Program.
  • Daisy Wong, PhD -- Adjunct Assistant Professor at the Computer and Information Sciences at the University of Alabama at Birmingham. She teaches and also provides research and consulting to heath care analytics industry.

Additionally, the group would like to recognize the support we received from Rob Campbell, CEO of Voalte, and HIMSS in the creation of this document, particularly Tom Martin and Tim Castallo.

Here’s to mHealth!

The mHIMSS Policy and Regulatory Implications Workgroup


Office for Civil Rights: Health Insurance Portability and Accountability Act

Who is Responsible:

Individuals, organizations, and agencies that meet the definition of a covered entity under HIPAA must comply with the HIPAA Privacy and Security Rules’ requirements to protect the privacy and security of health information and must provide individuals with certain rights with respect to their health information.

  • Most doctor offices, hospitals, health plans, health care clearinghouses and insurance companies are covered entities.
  • Under the HITECH Act, HIPAA Privacy and Security Rules apply to business associates of covered entities. HITECH Act §13401.
  • A covered entity is any entity that receives federal financial assistance from the Department of Health and Human Services or is covered under Title II of the Americans with Disabilities Act as a program, service, or regulatory activity relating to the provision of health care or social services.
  • Are You a Covered Entity?
  • A “business associate” is a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity. A member of the covered entity’s workforce is not a business associate.

What and Why it is regulated:

Under the HIPAA Privacy and Security Rules, covered entities are required to take certain steps to ensure that their patients’ protected health information (PHI) remains private and secure. As stated above, under the HITECH Act, business associates must also comply with the HIPAA Privacy and Security Rules.

  • Protected Health Information: all "individually identifiable health information" held or transmitted by a covered entity or its business associate, in any form or media, whether electronic (ePHI), paper, or oral (PHI). ePHI is a form of PHI.
  • Examples:
  • Any demographic data, that relates to the individual’s past, present or future physical or mental health or medical condition
  • The past, present, or future payment for the provision of health care to the individual
  • Data for which there is a reasonable basis to believe can be used to identify the individual
  • Individual identifiable health information such as name, address, birth date, and Social Security Number

The Security Rule requires appropriate administrative, physical and technical safeguards to ensure the confidentiality, integrity, and availability to those who are authorized to see PHI. The key requirement of the security rule is to conduct a risk assessment and to address the results. The Security Rule is technology neutral, so its standards apply regardless of whether the covered entity is transmitting or receiving electronic protected health information from computer to computer, laptop to laptop, tablet to tablet, or smart phone to smart phone – or any other combination thereof.

The Privacy Rule gives the consumer rights over his/her health information and sets rules and limits on who can view or receive his/her health information.

How and When the Regulation Will be Enforced:

The U.S. Department of Health and Human Service’s Office for Civil Rights (OCR) is responsible for privacy and security enforcement of HIPAA. Currently the OCR is piloting a program to perform up to 150 audits to assess privacy and security compliance. Audits conducted during the pilot phase will begin November 2011 and conclude by December 2012.


This summary is based upon the HHS’, Understanding Health Information Privacy site.

Centers for Medicare and Medicaid Services: Meaningful Use

Who is Responsible:

Each Eligible Hospital (EH), Critical Access Hospital (CAH), or Eligible Provider (EP) must demonstrate that they are a “Meaningful User” of a certified electronic health record.

What and Why it is regulated:

This requirement was made law through the Health Information Technology for Economic and Clinical Health (HITECH) Act, which is part the American Recovery and Reinvestment Act (ARRA) of 2009. HITECH promotes the implementation and use of health IT and includes billions of dollars in incentive payments, and eventually, penalizes Medicare providers through reductions in their reimbursements. CMS is promulgating the Meaningful Use rules in three stages under the advisement of NIST and ONC. Additionally, for each stage of Meaningful Use, ONC will promulgate an associated standards rule set.

Currently, Meaningful Use is still in the incentive period. To qualify for an incentive, providers must meet Stage One objectives. Stage One objectives are split into a core group and a menu group. In order to meet Meaningful Use status, all objectives in the core group are required plus 5 of 10 objectives from the menu group for eligible professionals, critical access hospitals, and eligible hospitals. In addition, 15 Clinical Quality Measures are required for eligible hospitals and critical access hospitals and 3 core clinical quality measures (or 3 alternate core clinical quality measures) plus 3 additional clinical quality measures out of a set of 38 for eligible professionals. One of the required core objectives is the utilization of CPOE for eligible hospitals, critical access hospitals, and eligible professionals.

The relationship between Meaningful Use requirements and mobile devices intersect when defining the CPOE requirement of the core group. The Final Rule states that if CPOE occurs through the use of an application on a mobile device, that application must be certified for Meaningful Use as a complete EHR or module. It could be further deduced that any requirement that is fulfilled via a mobile device application would require the application to be certified.

How and When the Regulation Will be Enforced:

Meaningful Use requirements will be implemented in three stages; Stage 1 was defined in the final regulations released in July 2010. The Notice for Proposed Rule Making for Stage 2 is set to be released by the end of the 1st Quarter 2012, Stage 3 is proposed by the end of 2013. While Meaningful Use is currently in an incentive period, starting in 2015, providers will experience a reduction in their Medicare reimbursements if they fail to reach Meaningful Use requirements.


This summary was based off of CMS’ Meaningful Use page.



NIST: Test Procedure for ONC Certified EHR CPOE from Drug-Drug, Drug-Allergy Interaction Checks

Who is Responsible:

This guidance is targeted at eligible hospitals, vendors of ONC Certified EHR CPOE and ONC-Authorized Testing and Certification Bodies (ATCBs), who will use the test procedures to evaluate conformance of EHR technology to ONC’s requirements as defined by NIST.

What and Why it is regulated:

These test procedures define test criteria for EHRs. If the EHR does not meet these requirements, the eligible hospitals (EHs) will not meet Meaningful Use.

This test procedure is organized into two sections:

  • Generate and indicate notifications – evaluates the capability to generate and indicate in real-time notifications at the point of care during computerized provider order entry (CPOE) for drug-drug and drug-allergy contraindications based on the patient’s medication list and medication allergy list.
    • The Vendor identifies specific alerts available in the EHR and available CPOE orders that can be used to initiate those alerts.
    • The Tester enters new medication orders via CPOE and generates at least one each of drug-drug and drug-allergy notifications identified by the Vendor.
    • The Tester validates that the notifications are generated and indicated to the user in real-time during CPOE, are based on the patient’s medication list and medication allergy list, and are displayed as defined by the Vendor.
  • Adjust notifications – evaluates the capability for certain users to make adjustments to drug-drug and drug-allergy interaction checking.
    • The Tester selects and displays the drug-drug and drug-allergy notification adjustment capabilities identified by the Vendor for this test.
    • The Tester adjusts at least one each of the selected drug-drug and drug-allergy notification rules; an example of an adjustment would be changing the level of severity of a notification for all user types or a specific user-type, for instance, causing the suppression of a drug-drug interaction notification for all CPOE users or only for cardiologists who order Digoxin and Furosemide together for the same patient.
    • The Tester validates, in real-time during CPOE, that the selected drug-drug and drug-allergy notifications have been adjusted as described by the Vendor.

This test Procedure requires the vendor to supply the test data. The Tester shall address the following:

  • Vendor-supplied test data shall ensure that the functional and interoperable requirements identified in the criterion can be adequately evaluated for conformance.
  • Vendor-supplied test data shall strictly focus on meeting the basic capabilities required of an EHR relative to the certification criterion rather than exercising the full breadth/depth of capability that an installed EHR might be expected to support.
  • Tester shall record as part of the test documentation the specific Vendor-supplied test data that was utilized for testing.

How and When the Regulation Will be Enforced:

For an eligible hospital to receive EHR Incentive payments from Medicare and Medicaid they must be able to validate the capabilities listed above. An ONC-Authorized Testing and Certification Body (ATCB) must use these procedures when certifying an EHR for ONC.


This summary is based upon NIST’s Test Procedures for Drug-drug, drug-allergy interaction checks.


Food and Drug Administration: Mobile Medical App Guidance

Who is Responsible:

This guidance is targeted at manufacturers and distributers of mobile medical apps.

  • Manufacturer” encompasses any person or entity that manufactures mobile medical apps in accordance with 21 CFR Parts 803, 806, and 807. Includes: anyone who initiates specifications, designs, labels, or creates a software system or application in whole or from multiple software components. Does not include: developers who strictly operationalize a manufacturers’ design.
  • Distributor” refers to entities that exclusively distribute mobile medical apps. Distributors are expected to work with manufacturers in correcting/removing products, but are not responsible for seeking FDA approval. Common distributors include the iTunes store, Android marketplace, and Blackberry app world.

What and Why it is regulated:

A “mobile medical application” or “mobile medical app” is a mobile app that meets the definition of "device" in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act); and its intended use is: as an accessory to a regulated medical device; or to transform a mobile platform into a regulated medical device. These devices are regulated to protect patients from unexpected harms.


  • Displaying, Storing, or Transmitting: If a mobile medical app allows for the display/storage/or transmission of patient-specific information, such as personal health information (PHI), in its original format, it is a medical device. This category of mobile medical apps are primarily used as secondary displays (and not for primary diagnosis/treatment decisions) and will only require Class I requirements. For example, a PACS Viewer (like Centricity® Radiology Mobile Access 2.0 software[i]) or mobile ECG viewer (like AirstripTM RPM Cardiology[ii] device) would be regulated under this criterion.
  • Controlling connected medical devices: If a mobile medical app allows for the control of another medical device, it must adhere to the regulations applicable to the connected device. These mobile medical apps can control the use, function, modes, or energy source of a regulated medical device. For example, an app that controls a blood pressure cuff (like Withings®[iii] blood pressure monitor) or a portable ultrasound app (such as the Mobisante software[iv]).
  • Mobile platform transformation: If a mobile medical app transforms a mobile platform into a regulated medical device, it is regulated under the class applicable to its intended use. For example, if a mobile medical app utilizes a phone’s accelerometer to collect data on Parkinson’s disease such as iTrem software.[v]
  • Interpretation of Medical Device Data: If a mobile medical app is intended to analyze or interpret data from a medical device for the purposes of creating alarms, recommendations, or information, is considered an accessory to the first medical device and regulated under the first medical device’s class. This would include patient monitoring apps such as the LifeWatchTM cardiac monitoring system.[vi]

How and When the Regulation Will be Enforced:

If the mobile medical app falls within a specific medical device classification or augments functionality to a specific medical device classification, manufacturers are immediately subject to meet the requirements of that classification (either I, II, or III).


This summary is based upon the FDA’s Mobile Medical Apps site.

Federal Communication Commission

Who is Responsible:

Device manufacturers are responsible to design and manufacturer their devices according to the FCC Specific Absorption Rate (SAR) limits. Some examples of devices which might fall under FCC oversight include insulin/glucose monitors, wireless heart monitors, medical radios, and/or cell phones.

What and Why it is regulated:

The FCC regulatory effort has been focused on protecting human health from negative RF (Radio Frequency) exposure and to prevent potential interference among mobile health devices such as implanted cardiac pacemakers. The allowable FCC SAR limit for RF energy exposure from wireless devices is 1.6 watts per kilogram (W/kg), as averaged over one gram of tissue.

Research to determine the health effect of RF exposure is ongoing by various organizations including the FDA and WHO. There are varied interpretations of reports that links wireless device use and cancer and other illnesses. Therefore, the FCC is closely monitoring these study results but has no basis so far to change the current SAR requirement.

How and When the Regulation Will be Enforced:

All wireless devices sold in the US go through a formal FCC approval process to ensure that they do not exceed the maximum allowable SAR level when operating at the device’s highest possible power level. If the FCC learns that a device does not confirm with the test report upon which FCC approval is based – in essence, if the device it stores is not the device the FCC approved, the FCC can withdraw its approval and pursue enforcement action against the appropriate party.

In addition, Wireless Medical Telemetry Service (WMTS) devices used within a health care facility must be registered with the FCC’s designated frequency coordinator and demonstrate that the devices operate within the WMTS spectrum.


This summary is based upon material on the FCC website.



Federal Trade Commission (FTC)

Who is Responsible:

The consumer data privacy guidance is targeted at policymakers and business that collect data through computers, mobile devices and mobile applications that can be reasonably linked to a specific consumer, computer, or other device. The policies on advertising apply to advertisers.

What and Why it is regulated:

FTC’s proposed framework for consumer data advocates companies to incorporate consumer privacy protection in their businesses; to provide choice to consumer on the use of his or her data; to be transparent with their data practices; to educate consumers on data privacy practices, and provide reasonable access to the consumer data that they maintain. In regard to consumer data privacy, companies do not need to provide choice before collecting and using consumers’ data for commonly accepted practices, such as product fulfillment.

FTC Framework: Consumer Data Privacy Protection

Regarding consumer data privacy protection, the FTC framework includes the following three principles for companies:

  • Companies should incorporate substantive consumer privacy protections throughout their organizations and at every stage of the development of their products and services.
  • Companies should simplify consumer choice. For collection of consumer data for uncommon practices and uses, companies should offer the choice in a simple way at a time and in the context in which the consumer is making a decision about his or her data.
  • Companies should increase the transparency of their data practices and educate consumers on commercial data privacy practices.

FTC Framework: Advertisements

Regarding advertising, the FTC has the following policies in place to guide advertisers:

  • Federal Trade Commission Act
  • Deception Policy Statement
  • Unfairness Policy Statement

How and When the Regulation Will be Enforced:

The FTC regulatory efforts focus on protecting consumer (particularly minors) data privacy and preventing fraudulent or deceptive marketing/advertising that misleads consumers. It will exercise regulatory authority over products and services regardless of the hardware or platform involved. The FTC utilizes the existing FTC Act and laws to determine violations. There are no additional requirements for mobile applications or devices in their current guidance and regulations.


This summary is based upon material on the FTC website.

[iii] Withings is a trademark or a registered trademark of Withings SAS France.


[vi] LifeWatch is a trademark or a registered trademark of LifeWatch Holding Services, Inc.

[1] Please note, Ms. Jacobs was not involved in the development of any of the guidances/regulations profiled in this summary and her work does not represent the official views of the FDA, HHS, or ORISE. She was enabled to participate through her ORISE fellowship, funded through an interagency agreement between the DOE and HHS/FDA.