Grantees of HIE Funds Get "PIN-ned" on Privacy, Security and Patient Consent

 Pushpin.jpgOn March 22, 2012 HHS/ONC released a new Program Information Notice (PIN) called the "Privacy and Security Framework Requirements and Guidance for State Health Information Exchange Cooperative Agreement Program" (P&S PIN).  The P&S PIN applies to all State Health Information Exchange Cooperative Agreement Program Recipients, including State Designated Entities (SDEs), SDE sub-grantees, and other direct grantees of the federal HIE Cooperative program. Here is a link to the HHS/ONC PIN website.

The P&S PIN requires all SDEs to submit as part of a 2012 annual SOP (Strategic and Operational Plan) an update of their privacy and security framework consisting of all relevant statewide policies and practices adopted by recipients, and operational policies and practices for HIE services being implemented by Grant recipients of funding in whole or in part with federal cooperative agreement funds (HIE Grant Recipients).

Among other things, each HIE Grant Recipient will need to submit how their existing privacy and security policies align with each domain of the Fair Information Practices (FIPs), which the ONC and the ONC's Privacy & Security Tiger Team have each previously pointed to as providing a privacy and security framework for networked HIE.  The FIPs are:

  1. Openness and Transparency
  2. Collection and Use and Disclosure Limitation
  3. Safeguards
  4. Accountability
  5. Individual Access
  6. Correction
  7. Individual Choice
  8. Data Quality and Integrity

Specifically, Point-to-Point Directed HIE Exchange Models will be required to demonstrate that their P&S policies address FIPs 1-4, and have the option of addressing FIPs 5-8. HIE models that aggregate data will be required to demonstrate that their P&S policies address FIPs 1-8. If any GAPs exist between a FIP and the HIE Grant Recipient's current policies (i.e. a domain is not addressed), this must be identified and a strategy timeline and action plan for addressing these gaps in the 2012 SOP update must be provided.

One of the most debated topics with networked HIE has been patient consent. Many HIEs and stakeholders have asked the federal government on guidance on when and what form of consent is required for networked HIE.  

The P&S PIN addresses patient consent with HIE, and requires that aggregated HIE models offer, at a minimum, individuals with a meaningful choice with regard to whether their individually identifiable health information (IIHI) may be exchanged through an HIO entity that aggregates data.

The P&S PIN then further goes on to define “meaningful choice” as including:

  • Made with advance knowledge
  • Not used for discriminatory purposes or as condition for receiving treatment
  • Made with full transparency and education
  • Commensurate with circumstances for why IIHI is exchanged
  • Consistent with patient expectations
  • Revocable at any time

Notably, the P&S PIN confirms that both opt-in and opt-out are acceptable means of satisfying patient choice. On Wednesday, March 27th,  I had the opportunity to speak at the HIPAA Summit in Washington D.C. where an audience member asked whether a “no choice” HIE model is now no longer a viable option for HIE.  Both Joy Pritts, ONC Privacy Officer, and Deven McGraw, Co-Chair of the ONC P&S Tiger Team, confirmed that at least with respect to HIE Grant Recipients who are operating an aggregated HIE model, the P&S PIN must be followed and each patient must be afforded with meaningful choice to participate in networked HIE. It's also important to note that while the P&S PIN requirement could potentially be satisfied through obtaining written consent from the patient, written consent is not required and, moreover, Ms Pritts specifically pointed out that obtaining a written blanket consent without any supporting meaningful processes would not meet the FIP standard. Thus, whether an opt-in or opt-out model is used, HIOs must focus on ensuring that educational information about HIE is being delivered to patients, and the patient's decision-making process is meaningful.

The FIPs are nothing new, and ONC actually issued its Nationwide Privacy and Security Framework for Electronic Exchange of Individually Identifiable Health information back in December of 2008!  Ever since then, I have been advising HIE initiatives to BUILD their HIE Policies around the FIPs and this ONC guidance document. Here is an example of how I crosswalk the FIPs with my template set of HIE Policies for HIOs that aggregate IIHI.

For a copy of a sample set of our HIE Policies, email me at, or visit which going live soon as a source for legal forms and templates.

Peeling Back BCBS's $1.5 Million HIPAA Settlement Onion


As many of our readers have already heard, on March 13, 2012 HHS announced that Blue Cross Blue Shield of Tennessee entered into a Resolution Agreement for $1.5 Million Dollars to settle potential violations of HIPAA. You can access a copy of the Resolution Agreement here

I find this new case both instructive and frightening, but one has to peel back the layers of this HIPAA-onion to really understand why the Resolution Agreement between BCBS of Tennessee (BCBSOTenn) and HHS/OCR creates an even greater nerve-racking precedent than may be immediately apparent.

First, it must be noted that OCR initiated its investigation of the Breach incident and BCBSOTenn only after BCBSOTenn submitted its HITECH Breach Report "in compliance with" 45 CFR §164.408.  Therefore, HHS/OCR appears to acknowledge that BCBOTenn's reporting of the Breach was timely, proper and otherwise in compliance with the Breach Notification Rule.  And, while BCBSOTenn did not seem to get much reprieve here for its diligent Breach reporting, it’s important to point out that just because a covered entity experiences a Breach does not in and of itself mean that the covered entity has violated the HIPAA Privacy or Security Rule.  A covered entity must actually fall short of or be non-compliant with a HIPAA Privacy Rule standard or Security Rule standard before an actual violation can be found.

So, at least hypothetically, a covered entity could still be in full compliance with the HIPAA Privacy and Security Rules, even if it experienced a Breach involving or potentially compromising PHI.

In such a situation, as long as the covered entity properly and timely reports the Breach as required under the HITECH Breach Rule, and has a fully compliant, current and effective HIPAA compliance program implemented, then the covered entity should be able to assert that there were no violations of HIPAA or HITECH to give rise to HHS/OCR assessing penalties against it.  However, at least for BCBSOTenn, apparently the costs and burden of going through an investigation to prove that the Breach was not due to an underlying lapse its HIPAA compliance program was not worth it, at least not $1.5 Million.

What may be most chilling from a compliance perspective here, however, is that the Breach incident itself was allegedly caused by an intervening criminal act, and that BCBSOTenn had presumably paid Eastgate to provide security services to safeguard the data closet where the video and audio recordings were being temporarily stored until their scheduled relocation at the end of November 2009;  and, indeed, it seems that Eastgate did have a lot of appropriate physical safeguards in place, including biometric and keycard scan security with a magnetic lock, an additional door with a keyed lock, and basic security services.

So, if BCBSOTenn contracted, paid for and relied on Eastgate to provide security services, one would think that it would be reasonable for BCBSOTenn to believe that it had taken appropriate steps to attempt to safeguard the e-PHI while it was temporarily stored at the data closet.  What is not discussed in the Resolution Agreement, however, but would be interesting to know is whether BCBSOTenn’s contract with Eastgate included HIPAA BAA-type language to ensure that Eastgate was aware of the sensitive nature of what they were securing (i.e., e-PHI), and to contractually obligate Eastgate to have in place at least minimum administrative, technical and physical safeguards with regard to how it ensured the security of the data closet.  This illustrates a good lesson, which is while a security vendor or a building manager may not technically be a HIPAA BA, as historically defined by HHS (because such third parties are not required to access PHI to perform their function on behalf of the covered entity), in any instance where a covered entity relies on a third party to ensure the security of its PHI or e-PHI, including software vendors, data warehouses, cloud providers and other similar types of third parties, it is important to have such third party contractually agree to have in place HIPAA BA-type safeguards, and to agree to be responsible for any damages that may arise from a Breach that is due to their own negligence. In this case, Eastgate did not respond to evaluate an unresponsive gate for the entire weekend. While it is not clear whether this may or may not have been negligent on the part of Eastgate, hopefully BCBSOTenn had provisions in its agreement with Eastgate that required insurance coverage for such incidents and will allow BCBSOTenn to also potentially make a claim for indemnification if there was indeed fault on the part of Eastgate.

Finally, despite the fact that the theft of the e-PHI was the event that precipitated HHS/OCR to conduct an investigation here, it almost seems that its settlement with BCBSOTenn had less to do with the actual Breach incident itself and more to do with what HHS/OCR may have believed could be lacking with BCBSOTenn’s general HIPAA compliance program.  In fact, the corrective action plan (CAP) in the Resolution Agreement does not include any requirement to take any actions, like encryption, with regard to similarly stored data devices.  Instead, the CAP focuses on HHS/OCR having the opportunity to review BCBSOTenn’s written policies for conducting a risk assessment, conducting a risk management plan, addressing facility access controls and a facility security plan, and addressing physical safeguards governing the storage of e-PHI.  The CAP also requires such policies to be revised, IF HHS/OCR suggest “material changes” to the policies, and to be distributed to all BCBSOTenn workforce, who must then sign a certification of receipt, and be retrained. Now, while that is all well and good, I wonder about HHS/OCR focusing on BCBSOTenn workforce when wasn’t it the employees of Eastgate who were the ones that did not respond to the lapse in security?  At least in this instance, then, the real security gap seemed to be with BCBSOTenn’s contracted security vendor’s workforce, not its own.

This case certainly raises questions and concerns with investigation and enforcement processes, but also offers some instruction.  First, it is important for covered entities to review their contracts with third parties that may have access to PHI, and most certainly if such third party may be directly or indirectly responsible for ensuring the security of its PHI.  Covered entities should include clear language regarding allocation of responsibility for security, and severe repercussions, including potential indemnity, if the vendor falls short. Contracts with technology vendors, cloud providers, facility security providers, and the like are all potential areas where security weaknesses and gaps may exist.

Finally, while the outcome of the BCBSOTenn situation may tempt many to be more hesitant with reporting Breaches to HHS, that is not advisable.  Not reporting a Breach incident when it is legally required to be reported under the law could just lead to additional potential penalties for violations of the HITECH Breach Rule.  Thus, while Breach reporting clearly can lead to an OCR investigation, as it did here, the best defense may be for covered entities and business associates to ensure that their HIPAA Policies and Procedures are well-developed, updated, and implemented so that they can all be handed to HHS/OCR as proof of full HIPAA compliance, despite any Breach incident having occurred.


Meaningful Use Stage 2 NPRM Ramps Up HIE

With electronic health information exchange ("HIE") leaping out of the 132-page Meaningful Use Stage 2 Notice of Proposed Rulemaking ("Stage 2 NPRM), it is clear that while Stage 2 will continue to afford flexibility to eligible professionals ("EP"), hospitals and critical access hospitals ("CAH"), CMS is not shy about heightening its expectations for HIE.  The Stage 2 NPRM proposes several changes to existing Stage 1 objectives as well as proposes additional objectives for Stage 2 which would officially begin in 2014.

For starters, only one of the Stage 1 hospital core objectives involves HIE with "capacity to exchange key clinical information" satisfied by a test or even a failed test of exchange of clinical information with an outside health care provider.  And although four of the ten Stage 1 menu set objectives applicable to hospitals require HIE, at a minimum only one of these objectives would need to be satified out of the menu set objectives hospitals could choose from. Hospitals and EPs are required by Meaningful Use to meet all core objectives, whereas they have the option to choose from available menu set objectives (five of ten for hospitals in Stage 1, with two of four proposed in Stage 2), only one of which must be a population/public heath objective. 

The Stage 2 NPRM would move these Stage 1 public health/population menu set objectives to the core objectives for hospitals and EPs, with syndromic surveillance remaining a menu set measure for EPs.  Ongoing transmission of data to immunization registries as well as submission of data on reportable lab results and syndromic surveillance data to public agencies would also be required with testing no longer sufficient.

The Stage 1 core objective "capacity to submit key clinical information" would be removed effective in 2013 (with CMS welcoming comment on this and its replacement).  For Stage 2, hospitals and EPs would move instead to the now-core objective of "provide summary of care document" with 10% required to be provided electronically through HIE to other health care providers.  Likewise, new objectives and measures proposed for Stage 2 would also require HIE.  For EPs, new menu set objectives would require ongoing submission of data to cancer and specialized registries.  And for hospitals and EPs alike, although not proposed in the Stage 2 NPRM, CMS specifically requested comment on whether imaging results, which would have to be accessible through certified EHR technology as a new menu objective, should also be exchanged through HIE. 

Another area clearly marked on CMS's agenda is stronger patient engagement through HIE, with patient utilization actually required in order to meet certain objective measures. In Stage 1, for example, EPs and hospitals were required to provide patients with an electronic copy of their health information upon request.  The Stage 2 NPRM would propose to change this to requiring the ability of the patient to print, view, and download their health information online, but also to actually having a percentage of patients utilize this resource (10%).  If 10% of all patients did not choose to access their health information this way, an EP or hospital would fail to meet meaningful use.  EPs would also be required under the Stage 2 NPRM to use electronic messaging to communicate with at least 10% of their patients about their health information.  Only messages sent by a patient would count for numerator calculation. 

A public comment period will remain open for sixty days from the date of publication in the Federal Register (March 7 - May 7, 5pm) for both the Stage 2 NPRM and the Standards, Implementation Specifications and Certification Criteria NPRM.  EPs and hospitals are strongly urged to submit comments, whether in general to proposed Stage 2 NPRM requirements as well as in response to specific questions posed by CMS.