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.

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.

(meta-data) "TAG, You-Are-It" (ONC, CMS, DHHS) !

This December 2010, the President’s Council of Advisors on Science and Technology (“PCAST”) released its Report titled “Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward,” and, boy, it makes meaningful use look like a walk in the park!

The Report notes, among many other things, that the current structure of available health IT systems is inadequate, resulting in user difficulty, unavailability of relevant information, such as best practices, limited capability for sharing data across systems, patient concerns regarding improper access, and the inability to search or aggregate and de-aggregate data where necessary for research, public health, quality improvement, or patient safety. In essence, current health IT systems cannot easily support the desired outcomes. The Report identifies key legislation and regulations responsible for moving the development of health IT forward, namely, HITECH and the “meaningful use” EHR Incentive Program, as well as demonstration projects to develop experience and the necessary conditions for progress. However, the Report stresses the urgency of accelerating and redirecting much needed federal groundwork for HIE.

The Report notes the successes of early adopters of integrated EHR systems (i.e., Kaiser Permanente and VHA), while recognizing areas of functionality still in dire need of improvement, such as interoperability. It finds data exchange and aggregation central to accomplishing potential health IT benefits yet rejects current HIE models as being “ill-suited” as the basis for a national health information infrastructure due to durability and interoperability concerns. PCAST considers new technologies, such as “cloud-based” EHR products, patient personal health records, and data aggregation “middleware” products for interoperability that have potential to remove barriers and create solutions, as well as other promising models for data exchange.

PCAST rejects standardized health record formats and service-oriented architecture (SOA) in favor of metadata-tagged data elements and data-element access services (DEAS), the advantages of which the Report describes in detail. Such “tags” are small pieces of information accompanied by a larger “megadata tag” which groups them by attributes as well as required privacy and security protection.

The Report argues that a universal exchange language based upon tagged dataelements (i.e., DEAS and metadata-tagged data) is more sophisticated and better for privacy and security.

For example, DEAS would require authentication of an individual into the system and allow only access to information based upon the role he or she is assigned. To obtain access to encrypted tagged data elements, based upon a patient’s privacy choices, the individual would have to have the proper credentials and role. It is also crucial to note that the Report rejects that such a system would require “universal patient identifiers” or create a central repository of patient information.

Furthermore, the Report explores how HIPAA is ill-equipped, and possibly detrimental to medical research and care, to handle the changes in health IT and how HITECH both partially remedies and exacerbates this situation, such as accounting of disclosures which will “stifle innovation”.

Finally, the Report argues that federal leadership is necessary to combat economic concerns and incentivize information exchange and development of health IT systems. Adopting standardized metadata, aligning economic incentives (such as through “meaningful use”), encouraging technological innovation and competition, supporting development of network infrastructures through appropriately designed pilot projects, and developing a regulatory health IT structure along with regulatory oversight all are suggested by the Report as necessary.

PCAST detail several layers and roadmaps for government agencies to progress towards the realization of a national health IT infrastructure. It also recommends guidelines for transitioning from existing EHRs and information exchange systems to the new tagged data element model advocated by the Report, and addresses generation of necessary early design choices by ONC and the Report’s vision for future CMS meaningful use requirements. The Report concludes with specific short and mid-term recommendations for ONC, DHHS, CMS, and other agencies in order to realize the objectives outlined in the Report towards establishment of a national health IT infrastructure.   In response, ONC, for one, appears to have already set up a PCAST Report Workgroup, and the first meeting is scheduled for January 14, 2011.

 To review PCAST’s summary of Recommendations of who should do what next, click Continue Reading below.

Continue Reading

The 800-Pound HIE Gorilla Tiger in "Meaningful Use"

There has been a lot of discussion around the Meaningful Use (MU) criteria. CMS has an entire website dedicated to the subject, as does ONC. Although the clinical criteria of MU may garner much of the attention, the privacy and security components are also significant.  In particular, the MU criteria pertaining to Health Information Exchange (HIE) raise certain fundamental privacy questions.

In short, the HIE requirements for MU include the ability to: (1) exchange “key” clinical information among providers of care and patient authorized entities electronically, and (2) perform at least 1 test of exchanging information. The crucial question, then, is what exactly does "and patient authorized entities" suggest?  In listening to the privacy discussion taking place in various ONC Workgroups, including the newly-established Privacy & Security Tiger Team, one could reasonably conclude that this requirement might evolve to mean that a HIE will need to be able to capture and implement patients' specific and granular preferences (e.g., patient is "ok” with releasing info to Provider B, but not to Provider C) -- at least if you want to meet MU criteria

This interpretation, however, could throw a wrench into HIE networks across the nation that have implemented an Opt-Out consent model in part in reliance on a legitimate belief that when HHS adopted the final version of the HIPAA Privacy Rule it also vetted and already decided the question of whether a patient's prior written authorization should be required before general health information can be shared between treating providers for treatment purposes -- and it affirmatively decided to create the "Treatment Exception".  In fact, many states have laws that contain a similar exception. New Jersey, for example, specifically permits two treating doctors to share pertinent information about a common patient and expressly states that the prior consent is not required in such instances if it is in the best interest of the patient (see N.J.A.C. 13:35-6.5(d)3).

Links to the full legislative history related to the promulgation of the HIPAA Privacy Rule can be found on HHS’s website, but, a closer look at the August 14, 2002 “Modification to the HIPAA Privacy Rule –Final Rule" are worth a second read in particular.  For those who wish to review it in full, I have posted a full exerpt of the relevant sections under the “Continue Reading” window below, but in sum HHS removed the requirement of obtaining prior patient authorization after reviewing numerous public comments on the issue and concluding that:

As a result of the large number of treatment-related obstacles raised by various types of health care providers that would have been required to obtain consent, the Department became concerned that individual fixes would be too complex and could possibly overlook important problems. Instead, the Department proposed an approach designed to protect privacy interests by affording patients the opportunity to engage in important discussions regarding the use and disclosure of their health information through the strengthened notice requirement, while allowing activities that are essential to quality health care to occur unimpeded ...

The Final HIPAA Privacy Rule was adopted after HHS released multiple proposed versions, considered significant public comment, and followed administrative rule-making procedures -- all over the course of almost 3 years. Thus, as policies are recommended and developed for the HIE context, prior debate and dialogue is relevant and should not be forgotten or dismissed.

Continue Reading