Proposed Rule for Meaningful Use Stage 2 Released

Yesterday, the Meaningful Use Stage 2 Proposed Rule was made available on the Office of the Federal Register Electronic Public Inspection Desk.  The Proposed Rule will be published March 7 and will be open for public comment for sixty days.

With a focus on data exchange, the Proposed Rule addresses the Stage 2 meaningful use criteria that eligible professionals and hospitals must meet as well as proposes certain changes to existing Stage 1 criteria.  Nearly all Stage 1 core and menu objectives would remain in place for Stage 2, and eligible hospitals would be required to meet 16 core objectives and 2 out of 4 menu objectives.  Eligible professionals would be required to meet 17 core objectives and 3 out of 5 menu objectives. 

CMS has specifically requested public comment regarding processes for electronic clinical quality measure (CQM) reporting.  Eligible hospitals would be required to report on 24 CQMs with eligible professionals reporting on 12.  The Proposed Rule would also include clinical quality reporting within the definition of "meaningful EHR user" and remove it as a separate objective beginning in 2013. 

Another significant area made more robust by the Proposed Rule is the ability of patients to have electronic access to their health information (e.g., view, download), rather than access to only electronic copies of their information and discharge instructions as originally required by Stage 1.  Additionally, hospitals and eligible professionals are also required in connection with the HIPAA risk assessment that must be performed to specifically address encryption/security of EHR data at rest.  While the Proposed Rule would not require actual implementation of encryption mechanisms, it would require each hospital and eligible professional to assess the reasonableness and appropriateness of encrypting electronic PHI, and, if not reasonable, adopting alternative equivalents. 

Other proposed changes, although by far not an exhaustive list, include:

  • A more "robust" "transitions of care" core objective instead of the core objective of Stage 1 "exchange of key clinical information", requiring exchange of summary of care records for each transition or referral of care;
  • Requiring utilization of clinical decision support intervention for improving performance on high priority health conditions to relate to 5 or more CQMs which the EP or hospital would be required to report on (proof of actual improvement not required);
  • Consolidation of certain Stage 1 objectives within Stage 2 objectives:
    • "Use clinical decision support to improve performance on high-priority health conditions" would include Stage 1 drug-to-drug and drug-allergy checks
    • "Summary of care record for each transition or referral of care" would include Stage 1 active medication, allergy and problem lists
    • eRX objectives for eligible professionals and hospitals would include Stage 1 drug formulary checks
  • Expansion of CPOE to medication, laboratory and radiology orders, clarification on how and when CPOE must occur, and increase of measure from 30% to 60% of orders created;
  • Secure e-mail protocols
  • Expansion of the definition of a Medicaid patient encounter;
  • Process for Medicare payment adjustment beginning in 2015; and
  • Official delay of Stage 2 until 2014.

The ONC Standards and Certification Proposed Rule with additional guidance and standards for certified EHR technology is also expected to be released today so stay tuned.  

Feb 29th is Last Day to Report Breaches of <500 to HHS!

For those that have been logging their "small" Breaches (i.e., less than 500 individuals affected) and waiting to report them to HHS at the end of the year, next Wednesday, February 29th is the LAST day to get your information entered into HHS' Breach reporting website.  While covered entities may opt to report each small Breach to HHS throughout the year (i.e., including the onsies and twosies), the other option is to log each small Breach during the calendar year and report all such small breaches to HHS within 60 days of the end of such applicable calendar year. 

A couple of important points to note about reporting small breaches to HHS:  

First, the HHS-reporting "buck" stops with the covered entity, not the Business Associate. Even if a breach was caused by a Business Associate (BA), under the current HITECH Breach Rule the BA's only reporting obligation is to the covered entity; the covered entity is solely responsible for reporting all reportable Breaches to HHS. 

Goldilocks.pngSecond, follow a 'GOLDILOCKS rule'  of 'Not too much, not too little -- just right'. Covered entities must report all relevant information requested on HHS' online reporting form. However, there are several fields that ask for a typed response.  For example, HHS asks for a "brief description of the breach" including how it happened, any additional information about the breach, type of media and PHI. HHS similarly asks the covered entity to describe "other actions taken" in response to the Breach. But, while a covered entity must report what it is required to report by law, offering too much infomation (including impermissibly disclosing patients' PHI, among other things) could land the covered entity in hot water.

Finally, you better have remembered to collect ALL the required information on your Breach Log!  A covered entity that is planning to report small Breaches at the end of the calendar year must plan ahead and know what information to collect and document, and hint: it's a lot of information that you might not be able to recall at the end of the year unless you documented it as you went along.  Among the information that covered entities should be collecting about each "small" breach includes:

  • Date of the Breach? 
  • Date the Breach was Discovered?
  • Approximate number of individuals affected?
  • What "type" of breach was it? (select: theft, loss, improper disposal, unauthorized access, hacking/IT incident, other, or unknown)
  • Location of the Breach? (select: laptop, desktop computer, network server, e-mail, portable electronic devices, electronic medical record, paper, other)
  • What type of information was involved? (select : demographic info, financial info, clinical info, other) 
  • What safeguards were in place prior to the Breach? (select: firewalls, packet filtering, secure browser sessions, strong authentication, encrypted wireless, physical security, logical access control, antivirus software, intrusion detection, biometrics) 
  • Date individuals were notified? (note: that this date should never be more than 60 days after the Date of Discovery entered, and in any case any "unreasonable delay" in notifying individuals (even if less than 60 days) could be a trigger a closer look by HHS).
  • Actions taken in response (select : privacy & security safeguards, mitigation, sanctions, policies and procedures, or other) 
  • Even though HHS withdrew the Interim Final Breach Notification Rule during the summer of 2010 (and even though we continue to wait for a final revised version of that rule to be published), covered entities are still required to report all Breaches (if there is a positive "Harm" determination) to HHS. HHS specifically points out on its website that "[u]ntil such time as a new final rule is issued, the Interim Final Rule that became effective on September 23, 2009, remains in effect."

    For Breach Notification training & education, click our Workshops button.

    HITECH Omnibus and AOD Rules Set for OMB Review

    Health Data Management reports that the long-awaited HITECH Omnibus Rule as well as the Accounting of Disclosures (AOD) Rule are set for OMB review.  Expected also are proposed regulations for Meaningful Use Stage 2.  HHS released its semi-annual regulatory agenda in January to the Office of Management and Budget (OMB).  As with other agencies, the agenda identifies key regulatory priorities over the next months.

    The HITECH Omnibus Rule is expected for publication in March of this year with the AOD Rule not until June.  The proposed regulations for Meaningful Use Stage 2 are still expected this month, February.  While OMB review could hypothetically take a matter of weeks, the OMB may take up to ninety (90) days to review regulations before publication, as well as potentially extend the deadline. 

    "Tapping" Apps for Physician Advice: No Waiting Room Necessary

    This past week, I stumbled across a fascinating article by Michael Millenson on the Health Care Blog (originally on that I almost bypassed entirely.  Described as a “social media darling”, the article focused on a relatively new health care service called “HealthTap.”  

    To me, the name “HealthTap” immediately implied an iPhone or other smart phone appplication or “app” like TapFish, a virtual aquarium, or TapFarm – a likely deliberate marketing scheme to tap into (pun intended) the success that apps have had.  With apps to calculate the amount of calories you burn, fitness workouts, curing acne, and instant access to WebMD and WebMD Baby, consumers are turning to app downloads for solutions to their health problems.  As we all know too well, there’s an app for pretty much everything (and indeed, there is, in fact, a HealthTap app). 

    I freely admit that I, like many others, don’t think twice about consulting WebMD and the like before my physician for any health questions I may have.  The availability and wealth of information and the ease which consumers can obtain it is a powerful attraction and a driving force behind over 9,000 health apps being available in the iTunes store.  Like many others, I generally only consult sources that to me appear reputable and from a trustworthy individual or organization. 

    At first glance then, HealthTap appears to be an applaudable solution to help individuals become more involved in their health care and seek answers to general health questions.  HealthTap states that,

    We help you better understand your health, make better health decisions, and find the best doctors...We believe that everyone has the right to free, reliable, and independent health information. We also believe that the most trustworthy health information comes from medical experts. Finally, we believe that the best health decisions take into account unbiased expert knowledge, community insights, and relevant data.

    Individuals can log on and create an account, either as a physician or as a member.  A member can pose a question which any physician that signs up for HealthTap can answer.  For each question answered by a physician, he or she is granted points and levels, building his or her “reputation” in HealthTap.  Answers can be categorized as “Yes”, “No”, “Maybe”, “Complicated Question”, “Evaluation” and the like.

    Because answers are only coming from a physician with supposed knowledge and expertise, not a random individual like with Yahoo Answers, it appears to be more credible and trustworthy.  In addition, HealthTap gives you information on physicians active on HealthTap who are in your area and their field or speciality.  It may give you their practice location and affiliations as well so you can choose to “follow-up” with a particular physician who answered your question if you so choose, establishing a bona fide physician-patient relationship. 

    Continue Reading

    ACO Rule Keeps HIE Consent "On the Fence"

    When DHHS published its Proposed ACO Rule in April 2011 and then the Final ACO Rule in November 2011 (I’ll refer to them as the “ACO Rules”), discussions focused predominately on issues such as who is “qualified” to participate, what the required governaConsent on the Fence.pngnce structure should be, what methodology will be used to assign Medicare beneficiaries, and what the payment models will be.  However, as I digested the ACO Rules, my reading deliberately slowed down as I zeroed in on the not unremarkable language and comments CMS included with regard to sharing individually identifiable health information in the ACO context.

    Among other things, the ACO Rules would authorize key data sharing between CMS and an ACO.  In particular, four categories of data could potentially be shared:

    • Aggregated Data
    • Personal Identifiers
    • Personally Identifiable Claims Data
    • Prescription Claims Data

    In the Preamble to the Proposed Rule, CMS emphasized the importance of sharing these forms of data in order provide more complete information for the services provided or coordinated for the ACO beneficiary populations, better achieve improvements in the quality of care and gain a better understanding of the population served while lowering the growth in health care costs. Notably, while the ACO Rules would permit Medicare beneficiaries to “opt-out” of certain data sharing, other data would be shared without the patient’s consent.  Moreover, it is clear that CMS deliberately chose to proceed with an opt-out approach, given its concerns regarding beneficiary participation and ACO Participant administrative burdens.  In the Preamble to the ACO Rules, it noted that:

    An opt-out approach is used successfully in most systems of electronic exchange of information because it is significantly less burdensome on consumers and providers while still providing an opportunity for caregivers to engage with patients to promote trust and permitting patients to exercise control over their data.”  See 76 Fed Reg. 19560 (2011). 

    Although some of the information that CMS proposes for “sharing” will be de-identified, other information will be identifiable. For example, limited beneficiary data (i.e., name, DOB, gender, insurance claim number) would be made available at the beginning of the first performance year and in connection with quarterly aggregated data reports.  Other data proposed to be shared could potentially include: (Medicare Part A & B) procedure codes; diagnosis codes; beneficiary IDs; DOB; geneder; date of dealth; claim ID; dates of service; provider/supplier ID; claim payment type; (Medicare Part D) beneficiary ID; prescriber ID; drug service date; drug product ID; if the drug is on the formulary. 

    CMS acknowledges in the ACO Rules that there could be privacy concerns with sharing identifiable information, but nevertheless takes the position that the HIPAA Privacy Rule permits disclosure for purposes of sharing Medicare Part A and Part B claims data with ACOs participating in the Shared Savings Program.  The agency also specifically notes that the disclosures of claims data would be permitted as “health care operations”.  Under HIPAA, a covered entity may disclose PHI to another covered entity for the recipient’s health care operations if they both have or had a relationship with the individual, the records pertain to that relationship, and the records will be used for a health care operation function meeting one of the first two paragraphs in the definition of health care operation under HIPAA. 

    Yet, although CMS explicitly states that it has the authority to share Medicare Claims Data without patient consent, the agency also notes that it “nonetheless believe(s) that beneficiaries should be notified of, and have meaningful control over who, has access to their personal health information for purposes of the Shared Savings Program.”  See 76 FR 19559; See also 76 FR 67849.  Therefore, while patients would not be able to opt-out of having de-identified aggregated data reports or limited identifiers shared with the ACOs, CMS will allow patients to opt-out of having claims data shared with the ACOs. 

    Over the past year, privacy, patient consent and HIE opt-in/opt-out continues to be debated (sometimes painfully).  The debate continues essentially because certain stakeholders hold different and strong views on if, when and at what point affirmative patient consent is required (under current law) or should be required (through promulgation of new rules).  As a result, some HIE collaboratives have required affirmative patient consent before any data is shared. Similarly, Recommendations from the ONC Tiger Team include, in part, that consent should be obtained before any information is shared with third parties, including Business Associates and HIOs(except where sharing is directed exchange (provider-to-provider), or between providers participating in an OHCA (as as side note, query if ACOs might qualify as OHCAs? least in some cases)).  Others have determined that the value of networked electronic HIE – i.e., healthcare quality improvement and cost reduction – is most efficiently realized when certain data is readily shared without prior authorization or consent, in accordance with HIPAA's exceptions, as a presumed default.  Now with CMS throwing its views on consent & opt-in/opt-out into the ring, at least with respect to ACO's data-sharing with Medicare, I'm sure many are anxious to see if the forthcoming HITECH Final Rule and NHIN Governance Rule will offer clear standards for the current HIE consent conundrum, or continue to precariously balance this issue on the fence....... I know I personally can't wait to see.

    State AG Brings First HIPAA Lawsuit Against Business Associate

    Last month, I posted how treatment of business associates during HIPAA investigations remains unclear as well as assignment of liability for breaches of PHI.  A final "omnibus rule" is expected to clarify the HITECH business associate (and other) provisions this year, but in the meantime, much confusion remains. 

    Despite the lack of final business associate rules, and confusion or not, Minnesota has dived head first into action against a business associate for HIPAA violations.  In the first HIPAA enforcement action directly against a business associate, Minnesota Attorney General Lori Swanson has brought an action against Accretive Health, Inc., pursuant to her authority under HITECH.  In addition, multiple violations of Minnesota law are alleged, including the Minnesota Health Records Act, debt collection statutes, and consumer protection laws.

    Accretive functions in multiple capacities for covered entities in Minnesota, including as treatment coordinator, debt collector and quality cost control and management partner.  A breach last summer of data compiled by Accretive resulting from a stolen unencrypted laptop left in a rental car by an employee affected at least 23,531 patients.  Information that was on the laptop included personal identifying information (name, address, phone number, Social Security Number), "medical scores" predicting the frailty, complexity and likelihood a patient would be admitted to the hospital, and dollar amounts allocated to the patient's health care provider, as well as whether patients had certain conditions such as bipolar disorder, depression, high blood pressure, asthma and back pain.

    The HIPAA violations are quite extensive, with the complaint alleging:

    • failure to implement policies and procedures to prevent, detect, contain and correct security violations;
    • failure to implement policies and procedures to ensure appropriate access to electronic PHI by members of its workforce and prevent those without authorized access from accessing such PHI in violation of HIPAA;
    • failure to effectively train all members of its workforce, agents and independent contractors, on the policies and procedures regarding PHI as necessary and appropriate to carry out their functions and maintain security of the PHI;
    • failure to identify and respond to suspected or known security incidents and mitigate to the extent practiable harmful effects known to them;
    • failure to implement policies and procedures to limit physical access;
    • faiilure to implement policies and procedures governing receipt and removal of hardware and electronic media containing electronic PHI within and without the facility;
    • failure to implement technical policies and procedures for electronic information systems to allow access only to those granted access rights; and
    • failure to implement policies and procedures as otherwise required by HIPAA.

    Almost more interesting than the alleged HIPAA violations (and what could potentially have been one of the driving forces behind the Attorney General taking action rather than the HIPAA violations), the complaint also alleges deceptive and fraudulent practices in that Accretive failed to disclose how much health information it was collecting on patients and its involvement in their health care, detailing in great length the importance of transparency for patients and the doctor-patient relationship.  In the press release, Attorney General Swanson stated,

    “Accretive showcases its activities to Wall Street investors but hides them from Minnesota patients.  Hospital patients should have at least the same amount of information about Accretive’s extensive role in their health care that Wall Street investors do.”

    This action has the potential to set precedent in Minnesota as to just how much transparency and information should be viewed as "necessary" for patients to make informed choices regarding their health care and medical records and the extent to which health care entities must take affirmative action to notify patients of their role in their health care.   

    Although the extensive HIPAA violations are merely one drop in the bucket of allegations against Accretive (e.g., fraud and deceptive practices, failure to notify of status as debt collector, release of health records in violation of the Minnesota Health Records Act), the enforcement action against Accretive makes it quite clear that covered entities aren't the only ones who need to be scrambling to get their ducks in a row.  While other state Attorney Generals have previously brought actions against covered entities (e.g., Vermont, Indiana, Connecticut), now that a state has gone after a business associate directly, it would not come as a surprise to see other states joining in, even despite the lack of business associate rules.

    For more information regarding what covered entities and business associates can do to prepare for a HIPAA audit or ward off the potential for enforcement action against them, see our November 17 blog post with links to additional HIPAA resources.  A copy of the complaint against Accretive may also be found here.