As you know - Meaningful Use Stage Two posted this week! Whoo hoo! There were a few changes from stage one and but from where I sit, it looks like things are aligned rather well. I did a summary of the NPRM (copy/pasted below (download it with pretty graphics here)), and also distributed by HIMSS. It's a pretty complete summary and highlights the differences between stage one and two. The only thing I didn't consider was the incentive/penalty structure. I'm not about to get into the business of telling people where the money's at!



HIMSS

HIMSS

Summary

The 2009 American Recovery and Reinvestment Act (ARRA) authorized incentive payments for the Meaningful Use of Electronic Health Records (EHR) through Medicare/Medicaid. This document is a high-level summarization highlighting the differences between the objectives in the Notice of Proposed Rule Making for Stage Two[i] and the Stage One Final Rule.[ii] CMS is “soliciting public feedback on several mechanisms for electronic CQM reporting, including aggregate-level electronic reporting group reporting options; and through existing quality reporting systems.”
Stage Two:

  • Eligible Providers (EPs): 17 core objectives, and 3 of 5 menu objectives
  • Eligible Hospitals and Critical Access Hospitals (EH/CAH): 16 core, 2 of 4 menu objectives

 This differs from Stage One:

  • EPs had 15 Core Objectives, 5 of 10 Menu Objectives, and 6 CQM.
  • EH/CAH had 14 Core Objectives, 5 of 10 Menu Objectives, and 15 CQM.

 

Timeline & Reporting

Reporting:

  • EPs: Calendar Year; EH/CAH: Federal Fiscal Year
  • 1st Year of MU (Stage One): Reporting Period is 90 days; Submission period is any time up to 2 months following the end of reporting period’s year
  • All other years of MU (All Stages): Reporting period, 1 year; Submission period, 2 months following the end of the reporting year

 Timeline:

The table below shows which Stage of Meaningful Use providers will need to achieve to receive incentive payments based upon their starting year.

First Payment Year

Payment Year[iii]

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2011

1

1

1

2

2

3

3

TBD

TBD

TBD

TBD

2012

1

1

2

2

3

3

TBD

TBD

TBD

TBD

2013

1

1

2

2

3

3

TBD

TBD

TBD

2014

1

1

2

2

3

3

TBD

TBD

2015

1

1

2

2

3

3

TBD

2016

1

1

2

2

3

3

2017

1

1

2

2

3

 

Guidelines and Definitions:

  • If a provider submits exclusion criteria for 1 of their menu sets, they are also attesting that they meet the exclusion criteria for all of the menu objectives that they did not select.
  • A Certified EHR must be used for at least 50% of a provider’s population over the entire reporting period. If the EP practices at multiple locations, this will include only patients seen at locations with certified EHRs.
  • Denominators will be one of four things:
    • Unique patients seen by the EP (stratified by age or previous office visit) or EH/CAH (stratified by age).
    • Number of Orders (medication, labs, radiology, imaging, and procedures).
    • Visits/Bed Days:
      • EP Office Visits: any billable visit that includes 1. Concurrent care/transfer of care visits; 2. Consultant visits or 3. Prolonged physician service without direct, face to face patient contact.
      • EH/CAH Inpatient bed days: admission day and each of the following full 24-hour periods during which the patient is in the inpatient dept of the hospital.
      • EPs will have latitude to include or not include telemedicine, minimal consulting services, and double counting (counting patient for both NP/PA and EP in same office).

Objectives

Changes to Stage One Criteria: 

  • This Stage Two rule alters some Stage One criteria – these changes will be optional in 2013 and required in 2014 (except otherwise noted):
    • CPOE: more than 30% of medication orders created by the EP/authorized providers at a EH/CAH are recorded using CPOE.
    • Vital Signs: addition of alternative age limitations (blood pressure will be only applicable for those over the age of three, while height/weight is for all ages) and exclusions (if all vitals, blood pressure, height/weight do not impact practice, provider does not have to record).
    • Exchange Key Clinical Data: Eliminated. Effective 2013.
    • Report CQM: Eliminated. Effective 2013.
    • Patient Electronic Communication: Same as Stage Two.
    • Public Health: Adds “except where prohibited” to language. Effective 2013.

 Differences between Stage One and Stage Two Criteria:

  • All Stage One Menu Set criteria are now in the core set, with the exception of two which will remain in the menu set: submitting syndromic surveillance data (EPs) and recording advanced directives (EH/CAH).
  • State Flexibility: States will continue to be able to specify transmission of data and public health measures so long as it does not require EHR functionality above and beyond that which is included in the ONC EHR certification criteria.
  • Other measures were Consolidated/Eliminated, including:

Consolidated/Eliminated Measures

Consolidated/Eliminated Measure

Logic

Drug/Drug and Drug Allergy Checks Combined into CDS.
Report CQM to CMS or States Completed with QMS reporting section of MU and not necessary as an objective.
Drug-Formulary Checks Combined into eRx
Maintain an up-to-date problem list of current and active diagnoses. Combined into Transition of Care.
Maintain active medication list.
Maintain active medication allergy list.
Provide patients with an electronic copy of their health information. Combined with objectives for online viewing and downloading
Provide patients with an electronic copy of their discharge instructions.
Capability to exchange key clinical information. Removed for Stage 2. Considering options for Stage 1.  Actual use case is more beneficial.


 



 

 

Stage Two

Objectives

Measure

Stage 1

Exclusions

Exclusions/Notes

Policy Priority: Improving quality, safety, efficiency, and reducing health disparities
Use computerized provider order entry (CPOE) for medication, laboratory and radiology orders directly entered by any licensed healthcare professional who can enter orders into the medical record per state, local and professional guidelines to create the first record of the order.  Core, 60%Numerator: CPOE OrdersDenominator: All orders Core, 30% Providers with less than 100 orders. Must be used the first time the order is placed and before any action can be taken on the order.This measure has changed from “% of patients with one order in their EHRs”
EP Only: Generate, Compare to one drug formulary, and transmit permissible prescriptions electronically (eRx).  Core, 65%Numerator:  eRxDenominator: all Rx Core, 40% Less than 100 Rx’s writtenNo electronically connected pharmacy within 25 miles Does not include controlled substances for schedules II-V as many vendor offerings lack the required DEA specifications. Will revisit for MU III.In 2015 the MIPAA eRX program will be phased out for MU.MU Stage One “compare to a drug formulary” menu objective is rolled into this one.
Record the following demographics as structured data
  • Preferred language
  • Gender
  • Race
  • Ethnicity
  • Date of birth
  • Date and preliminary cause of death in the event of mortality (EH/CAH Only)
Core, 80%Numerator:  Patients with all demographic information recordedDenominator: All Patients Core, 50% If the patient refuses to give the information the provider can count that patient in the numerator.
Record and chart changes in vital signs as structured data:
  • Height
  • Weight
  • Blood pressure (age 3 and over)
  • Calculate and display BMI
  • Plot and display growth charts for patients 0-20 years, including BMI
Core, 80%Numerator: Patients with information recordedDenominator: All patients Core, 50% No patients over the age of 3 years old.The provider believes that height/weight or blood pressure have no relevance to their practice
Record smoking status for patients 13 years old or older Core, 80%Numerator: Patients with information recordedDenominator: All patients over 13 years Core, 50% No patients over 13 years old
Use clinical decision support to improve performance on high-priority health conditions Core, Implement 5 CDS rules related to 5 or more clinical quality measures at relevant point.Implement Drug/Drug and Drug/Allergy Interaction Checks. Core, 1 rule Previously Drug/Drug and Drug/Allergy checks was a Core standalone objective.
Incorporate clinical lab-test results into Certified EHR Technology as structured data (either positive/negative or numerical). Core, 55%Numerator: Lab Tests recorded as structured dataDenominator: All Lab Tests Menu, 50% EPs who do not order labs that are in a yes/no or numerical format.
Generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research, or outreach. Generate at least one report listing patients of the EP, eligible hospital or CAH with a specific condition. Menu, 1 list
EP Only: Use clinically relevant information to identify patients who should receive reminders for preventive/follow-up care. Core, 10%Numerator: Number of patients in the denominator who received a reminder during the EHR reporting periodDenominator: Unique patients who have an office visit with the EP in the 24 months prior to the EHR reporting period Menu, 10% No office visits in the 24 months before the reporting period Different from stage one – requires the use of EHR to identify appropriate reminders instead of just sending reminders based on patient preference.
EH/CAH Only: Automatically track medications from order to administration using assistive technologies in conjunction with an electronic medication administration record (eMAR). Core, 10%eMAR is implemented and in use for the entire EHR reporting period in at least one ward/unit of the eligible hospital or CAH. N/A, New Measure A ward or unit is defined having unique staff, patient population, geographic location or function from other IP/ER Departments.
Policy Priority: Engage patients and families in their health care
EP Only: Provide patients the ability to view and download their health information within four business days of the information [labs, imaging, etc] being available to the EP. Core, 50%Numerator: Patients who can access their informationDenominator: Number of Unique Patients Core, 50% within 4 days Providers who provide 50% of their care in areas where 50% of their patients do not have at least 4 Mbps broadband availability
Core, 10%Numerator: Patients who access/download/transmit their informationDenominator: Number of Patient Visits N/A
EH/CAH Only: Provide patients the ability to view online and download information about a hospital admission within 36 hours of discharge Core, 50%Numerator: Patients who can access their informationDenominator: Number of Unique Patients New 50% of patients do not have at least 4 Mbps broadband availability
Core, 10%Numerator: Patients who access/download/transmit their informationDenominator: Number of Patient Visits N/A
EP Only: Provide clinical summaries for patients within 24 hours for each office visit. Core, 50% Numerator: Office Visits with Clinical SummariesDenominator: Office Visits Core, 50% within 3 days No office visits in reporting period
Use Certified EHR Technology to identify patient-specific education resources and provide those resources to the patient. Core, 10% Numerator: Patients provided resourcesDenominator: Number of Unique Patients Menu, 10% No office visits in reporting period
EP Only: Use secure electronic messaging to communicate with patients on relevant health information. Core, 10% Numerator: Patients receiving messageDenominator: Number of Unique Patients New
Policy Priority: Improve care coordination
Medication Reconciliation is performed upon receiving a patient from another setting of care.Most accurate list of all medications that the patient is taking:
  • Name
  • Dosage
  • Frequency
  • Route

 

Core, 65% Numerator: Patients for which MR was performedDenominator: Patients received from another setting of care Menu, 50% It’s unlikely to be an automated process so the electronic exchange of information is not required.“another setting of care” is from outside the organization.
Any provider who transitions their patient to another setting of care or provider of care or refers their patient to another provider of care should provide summary care record for each transition of care or referral. Core, 65% Numerator: TOC with Summary of Care Documents GeneratedDenominator:TOC/Referrals Menu, 50% Not the recipient of any TOC during the reporting period. Includes Eliminated Objectives:
  • Active Problem/Diagnosis List (Core, 50%)
  • Active Medication List (Core, 80%)
  • Active Medication Allergy List (Core, 80%)
Core, 10% Numerator: TOC with SOC generated electronicallyDenominator: TOC/Referrals N/A
Policy Priority: Improve population and public health
Capability to submit electronic data to immunization registries or immunization information systems. Successful ongoing submission. Menu, Test Ability If there are no appropriate agencies/registries to receive the information.If the registry/agency doesn’t accept electronic submissions format/standard specified by ONC’s certification rules.  If an HIE has been delegated to receive information on the agency/registry’s behalf this exclusion is not acceptable.Where prohibited, and in accordance with applicable law and practice. Stage 3 will likely be bidirectional.
EH/CAH Only: Capability to submit electronic reportable laboratory results to public health agencies, except where prohibited, and in accordance with applicable law and practice.
EP Menu; EH/CAH Core:  Capability to submit electronic syndromic surveillance data to public health agencies, except where prohibited, and in accordance with applicable law and practice. Core, Test Ability
Policy Priority: Ensure adequate privacy and security protections for personal health information
Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. Core.Conduct a security risk analysis in accordance with the requirements under 45 CFR 164.308


Menu Set Objectives

 

Eligible Providers (EPs): 17 core objectives, and 3 of 5 menu objectives

Eligible Hospitals and Critical Access Hospitals (EH/CAH):  16 core, 2 of 4 menu objectives.

Objectives

Measure

Stage 1

Exclusions

Exclusions/Notes

Policy Priority: Improving quality, safety, efficiency, and reducing health disparities
EH/CAH Only: Record advance directives as structured data for patients 65 years old or older who are admitted to the hospitals inpatient department. Menu, 50%Numerator: Patients with information recordedDenominator: All patients over 65 years Menu, 50% No patients over 65 years
Incorporate imaging results and information into/accessible through Certified EHR Technology.  Menu, 40% Numerator: Incorporated Imaging ResultsDenominator: Imaging Tests/Scans New No tests or scans Does not have to be structured data.Stage three is likely to include the exchange of the data.
Record patient family health history as structured data EHR reporting period for one or more first-degree relatives or an indication that family health history has been reviewed. Menu, 20%Numerator: Patients with Information RecordedDenominator: All Unique Patients New No Office Visits.

Objectives

Measure

Stage 1

Exclusions

Exclusions/Notes

EH/CAH Only: Generate, check against one formulary, and transmit permissible discharge prescriptions electronically (eRx). Menu, 10%Numerator: Rx GeneratedDenominator: Discharge Rx Written New Measure limited to new and changed Rx. Invited comment on whether refilled Rx should be included.
Policy Priority: Improve Population and Public Health
EP Only: Capability to identify and report specific cases to a specialized registry (other than a cancer registry). Successful ongoing submission. New Except where prohibited,  as appropriate to the provider’s practice, and in accordance with applicable law and practice
EP Only: Capability to identify and report cancer cases to a State cancer registry.
EP Menu; EH/CAH Core:  Capability to submit electronic syndromic surveillance data to public health agencies. Menu

Clinical Quality Measures

  • Many measures were put out in the NPRM, only a subset will be finalized.

EP CQM Measures: 125 Potential Measures

Two Options:

  • Option 1a: Select and submit 12 measures from the list of measures; one measure from each domain is required. If a provider’s EHR doesn’t include information for 12 measure, they must submit all of the measures that they can.
  • Option 1b: Report 11 “core” CQM, plus 1 “menu” CQM.
  • Option 2: Submit and satisfactorily report CQM under the Physician Quality Reporting System’s EHR Reporting Option (42 CFR 414.90).

Measures Include:

  • Conditions/Disease Management:
    • Asthma
    • Cardiology: Coronary Artery Disease, Ischemic Vascular Disease, Myocardial Infarction, Heart Failure, COPD, Atrial Fibrillation
    • Dementia
    • Eyes: Cataracts, Glaucoma
    • Hepatitis C
    • HIV/AIDS
    • Joints/Bones: Rheumatoid Arthritis, Osteoarthritis, Osteoporosis, Lower Back Pain, Knee/Hip Replacement
    • Kidney Disease
    • Oncology: General Oncology, Breast, Cervical, Colorectal, Colon, Prostate, Melanoma Diabetes
    • Otitis Externa
    • Psychiatric: Major Depressive Disorder, ADHD, Bipolar Disorder
    • Urinary Incontinence
    • Wound Care
    • Drug Management:
      • Antibiotic Use: Pharyngitis, Bronchitis, Upper Respiratory Infection, Perioperative Care
      • Asthma
      • ADHD
      • Cardiology: Heart Failure, Atrial Fibrulation, Coronary Artery Disease (CAD), Ischemic Vascular Disease (IVD), Myocardial Infarction (MI), Chronic Obstructive Pulmonary Disease (COPD),
      • Depression
      • Diabetes
      • Hypertension
      • HIV/AIDS
      • Kidney Disease
      • Oncology: Chemotherapy/Radiation/Pain, Colon, Breast, Prostate, Prostate
      • Osteoarthritis (OTC Assessments)
      • Perioperative VTE Prophylaxis and Antibiotic Timing
      • Preventative Care:
        • Alcohol/Drug Dependence
        • Antibiotic Use: Pharyngitis, Bronchitis, Upper Respiratory Infection, Perioperative Care
        • Blood Pressure
        • Chlamydia Screening
        • Cholesterol
        • Dental Decay
        • Immunizations: Flu, childhood, pneumonia, HCV, HBV
        • Falls Risk
        • Maternal/Prenatal Care
        • Tobacco Screening
        • Weight Screening
        • Medical Practice:
          • Adverse Event Reporting
          • Complex Chronic Condition Assessment
          • Diagnostic Imaging Reports
          • Medication Reconciliation
          • Specialist Referral Loop Closure
          • Use of High Risk Medications in Elderly


EH/CAH Measures: 49 possible measures

  Two options for attesting:

  • Select and submit 24 measures from a list of 49 measures (all 15 from Stage One are included); one measure from each domain is required.
  • Submit 24 CQM in a manner similar to the 2012 Medicare EHR Incentive Program Electronic Reporting Pilot (Medicare Hospitals Only).
  • Drug Management:
    • Antibiotics: Pneumonia, Perioperative
    • Asthma
    • Cardiology: AMI, HF,
    • Ischemic Stroke
    • Pneumonia (antibiotics)
    • VTE Prophylaxis
    • Disease/Condition Care:
      • Asthma
      • Cardiology: Heart Failure, AMI,
      • Immunizations: Pneumococcal, Flu
      • Ischemic Stroke
      • Labor/Delivery: hearing, elective births, surfactant, complications
      • Surgical: VTE Prevention, Antibiotics, Catheter, Hair Removal
      • Medical Practice:
        • Home Management Plan of Care
        • Emergency Department Throughput
        • PICU Pain Assessments
        • NICU temperatures

[1] Author’s Note:  This summary was based upon publicly available knowledge and does not represent the view of the FDA, HHS, or ORISE. The author was not involved in writing this NPRM; any errors or omissions are solely the author’s. This summary was supported in part by an appointment to the Research Participation Program at the Center for Drug Evaluation and Research administered by the Oak Ridge Institute for Science and Education through an interagency agreement between the U.S. Department of Energy and the U.S. Food and Drug Administration. The author can be reached at jess.a.jacobs@gmail.com.


[i] References to Stage Two of Meaningful Use were taken from the Notice of Proposed Rule Making Released Feburary 23, 2012. http://www.ofr.gov/OFRUpload/OFRData/2012-04443_PI.pdf

[ii]References to Stage One of Meaningful Use were taken from the Final Rule Released July 28, 2010 http://edocket.access.gpo.gov/2010/pdf/2010-17207.pdf

[iii] Taken from the NPRM, Page 28: http://www.ofr.gov/OFRUpload/OFRData/2012-04443_PI.pdf#page=28

mHimss

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.


Introduction

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.

Reference:

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.

Reference:

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.

Reference:

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.

Examples:

  • 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).

Reference:

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.

References:

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.

References:

This summary is based upon material on the FTC website.


[iii] http://mobihealthnews.com/11275/fda-clears-withings-iphone-blood-pressure-cuff/. Withings is a trademark or a registered trademark of Withings SAS France.

[iv] http://www.imedicalapps.com/2011/10/fda-sanctioned-mobile-health-apps-making-appearance/

[vi] http://www.lifewatch.com/siteFiles/1/319/5257.asp. 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.

fda-logo

Here's a quick summary of the FDA CDRH's Mobile Medical Apps guidance (edited by amazing mHIMSS Mobile Policy and Regulatory Implications Group members: Daisy Wong, Rebecca Kennis, Wendelyn Bradley, Michael Kuriland, and Lee Kim). While I've copy/pasted an early version here, the official HIMSS version is found here. Remember, don't take this as the word of the FDA- it was just us looking at what they said and making some educated analyses.

Guidance Bottom Line:

The FDA will exercise regulatory authority over mobile medical applications intended to perform a medical device function, regardless of the hardware or platform involved. The regulatory requirements manufacturers must meet are determined by the intended use of the mobile medical app.

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. This may include health systems, insurance companies, private software vendors, Health IT startups, physicians, nurses, etc.
    • Does not include:  Developers who strictly operationalize a manufacturers’ design. These people are likely technology programmers who are hired to make someone else’s application work.
  • 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 is, Might, and isn’t regulated:

Below is a detailed description of what is, might, and isn’t regulated by the FDA. Regardless of regulatory oversight, manufacturers are encouraged to follow the Quality Systems regulations to prevent harm in the development of all mobile apps.

What is Regulated - Mobile Medical Applications:

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:

  1. As an accessory to a regulated medical device; or
  2. To transform a mobile platform into a regulated medical device

Examples:

  • 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 accelelerometer 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]

What might be Regulated:

The FDA will exercise regulatory discretion regarding mobile apps that meet the FD&C’s device definition but are not an accessory to a regulated device or intended to transform a mobile platform into a regulated device. Manufacturers may proactively register, list, and seek approval/clearance for mobile apps that might meet the criteria for being mobile medical apps.

Examples:

Applications that might fall under regulatory oversight include:

  • Applications that remind people to manually input information for logging/tracking/graphing, such as the LogFrog DB Diabetes tracking application that reminds users to test their blood and log A1C results.[vii]
  • Patient education data viewers, such as the ActiveMDTM Patient education marketing.[viii]
  • Organization of personal health information – such as dosages, calories, doctor appointments, lab results, and symptoms. This might include something like iLog Lyme, and application that allows users to log the symptoms of Lyme disease and their medication dosages.[ix]
  • Over the counter medication lookup applications that provide the information available on drug labels such as the MEDIlyzerTM application.[x]

What isn’t Regulated:

Non-covered apps include: Electronic versions of reference materials that do not contain patient-specific information; health/wellness applications that do not intend to cure, treat, or diagnose; automated billing, inventory, appointment, or insurance transactions; generic aids (audio recording, note taking, etc); mobile EHRs or PHRs.

Regulatory Requirements:

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).

According to the Draft Guidance, these requirements include:

  • Class I devices: General Controls
    • Establishment registration, and Medical Device listing (21 CFR Part 807);
    • Quality System (QS) regulation (21 CFR Part 820);
    • Labeling requirements (21 CFR Part 801);
    • Medical Device Reporting (21 CFR Part 803);
    • Premarket notification (21 CFR Part 807);
    • Reporting Corrections and Removals (21 CFR Part 806); and
    • Investigational Device Exemption (IDE) requirements for clinical studies of investigational devices (21 CFR Part 812).
  • Class II devices: General Controls, Special Controls, and (for most Class II devices) Premarket Notification.
  • Class III devices: General Controls and Premarket Approval (21 CFR Part 814).

Approval Process:

Section Author: Daisy Wong

To meet the regulatory requirements described above, developers of mobile app should be mindful that preparing, filing, and waiting for FDA approval will take time and may cost a significant amount of money. The amount and types of resources needed and the duration of the approval process is dependent upon the app/device classification per the descriptions in the previous section. In addition, developers should also budget for the maintenance of the certification once approval is obtained.

Guidance Limitations:

This guidance provides the “current thinking” of the FDA and is iterative. Indeed, the FDA will monitor mobile apps not covered by this guidance to determine if additional/different guidances are necessary to protect public health. This guidance does not consider wireless safety considerations, clinical decision support software, quality systems software, or mobile medical apps intended to analyze, process, or interpret medical device data from more than one medical device. Separate guidances are forthcoming.

Definitions:

  • Mobile Platform: handheld commercial off-the-shelf (COTS) computing platforms, with or without wireless connectivity. Examples: smartphones, tablet computers, personal digital assistants, etc.
  • Mobile Application (Mobile App): software applications that can be executed on a mobile platform; native and web-based.
  • Regulated Medical Device: a product that meets the definition of "device" in section 201(h) of the FD&C Act and that has been classified or otherwise approved or cleared by the FDA. Regulated Medical devices usually profess an ability to diagnose, cure, mitigate, treat, or prevent disease, or are intended to affect the structure or any function of the body of man.
  • General Controls: include requirements regarding good manufacturing practice, labeling, registering all establishments with the FDA, listing all devices to be marketed and submitting a premarket notification [510(k)] before marketing a device.
  • Special Controls: may include special labeling requirements, mandatory performance standards and postmarket surveillance.
  • Premarket Approval: Premarket approval (PMA) is the FDA process of scientific and regulatory review to evaluate the safety and effectiveness of Class III medical devices

References:

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


[i] http://www.hospitalemrandehr.com/2011/12/02/centricity-gets-fda-510k-clearance-for-mobile-radiology-app/.  Centricity is a registered trademark of General Electric Company.

[iii] http://mobihealthnews.com/11275/fda-clears-withings-iphone-blood-pressure-cuff/.  Withings is a trademark or a registered trademark of Withings SAS France.

[iv] http://www.imedicalapps.com/2011/10/fda-sanctioned-mobile-health-apps-making-appearance/

[vi] http://www.lifewatch.com/siteFiles/1/319/5257.asp.  LifeWatch is a trademark or a registered trademark of LifeWatch Holding Services, Inc.

[vii] http://itunes.apple.com/us/app/id398879753

[viii] http://www.activemd.net/design-develop/patient-education-programs.php.  ActiveMD is a trademark of ActiveMD Patient Education.

[ix] http://itunes.apple.com/us/app/id405435677

[x] http://www.medilyzer.com/smart-phone-iphone.html.  MEDIlyzer is a trademark of MediLyzer Systems Inc.

Little red ribbons = totally awesome

Today was a big first in my life - the very first time I presented at a conference! I totally sent my mom this picture...

Little red ribbons = totally awesome

What was the presentation on? It was an overview of the opportunities that mHealth opens to us - specifically in helping manage, promote, and monitor health status in various populations. The presentation concluded with a "why is it important for students to understand the promise of mHealth?"