HIPAA “access report” potentially much simpler to implement, more valuable than accounting of disclosures

Among the provisions of the Health Information Technology for Economic and Clinical Health (HITECH) Act garnering significant attention are the changes to existing HIPAA requirements for covered entities to produce accounting of disclosures of protected health information and a new proposed requirement that entities and business associates also maintain (and furnish upon request) a record of accesses to individuals’ electronic health records. Both of these measures are addressed in a notice of proposed rulemaking (NPRM) published by HHS in the Federal Register in late May, the comment period for which closed August 1. Public objections to the proposed rules emphasize the administrative burden to health care organizations to collect and store the information required for accountings of disclosures and access histories, and the apparent lack of interest among members of the public in requesting this information from health care entities. While the two provisions share obvious functional elements, there are significant differences in both technical feasibility and practical relevance that justify separate consideration of the proposed rules, and in particular suggest that the new access record provision may be more difficult to dismiss using the arguments put forth to date.

Many industry watchers are more familiar with the proposed changes to the accounting of disclosure requirements, since those changes are spelled out in the HITECH Act (at §13405(c)), which most notably change the time period covered from six years to three and also remove the exception under current HIPAA provisions for disclosures for the purpose of treatment, payment, or health care operations. The NPRM repeats the current (45 CFR §164.528(b)(2)) implementation specifications for the content that must be included for each disclosure in the accounting:

• Date of disclosure
• Name of the entity or person (and their address, if known) receiving the disclosed PHI
• Description of the PHI disclosed
• Purpose for the disclosure

These requirements apply to PHI disclosed in both paper and electronic form, although the objections to the rule seem to focus on electronic disclosure, perhaps due to the inherent limitations of many electronic health record (EHR) systems and other applications to capture the required information. There are valid procedural objections as well, because with the exception of the date of the disclosure, the content required cannot easily be extracted or automatically recorded from EHR systems, and with respect to the purpose for disclosure in particular, it seems likely that the need to capture this information would insert a step in routine business processes where the purpose would need to be recorded before the process could be completed. By applying the accounting of disclosure to the types of disclosure that likely make up the vast majority of purposes for most health care entities, the removal of the exceptions for treatment, payment, and health care operations will unquestionably add to the administrative workload of covered entities and business associates who must comply with the law. Before developing the NPRM, HHS issued a request for information in May 2010 seeking comments on the accounting of disclosure changes in the HITECH Act, in which HHS sought to “better understand the  interests of individuals with respect to learning of such disclosures, the administrative burden on covered entities and business associates of accounting for such disclosures, and other information that may inform the Department’s rulemaking in this area.” Many commenters apparently pointed to the lack of consumer demand for accountings of disclosures, with few requests received by entities in the several years since the provision was first enacted. It seems possible however that while health care organizations will undoubtedly need to devote greater resources to complying with the revised rule, by covering a much greater proportion of total disclosures that individuals might find the accounting more valuable than in the past, when those requesting accountings would likely get no information regarding the most common or perhaps consumer-intuitive situations where disclosures had occurred.

Under the definition used in HIPAA (45 CFR §160.103), a “disclosure” only occurs when information leaves the entity holding it, so the accounting of disclosures only covers release or transfer of PHI from one person or organization to another. The new access report provision has no such limitation, and HHS indicated in its NPRM that it chose to add coverage for access to PHI by members of an entity’s workforce as part of an expanded perspective that includes both internal and external access to information in an individual’s health record. In contrast to the accounting of disclosures, the access report would apply only to records in electronic form, which might make the provision seem somewhat less comprehensive than the accounting of disclosures, but which – intentionally or not – greatly simplifies the collection and maintenance of record access information. The proposed implementation standard for the content of the access report specifies the following information:

• Date of access
• Time of access
• Name of the person accessing the record (if available, or else the name of the entity)
• What information was accessed, if available
• Action taken by the user (e.g. create, modify, access, delete)

With the exception of describing what information was accessed, all of the elements proposed in the implementation specification reflect data routinely captured in audit logs that can typically be automatically generated by database-centric computer systems such as those used to manage EHRs. Distinguishing subsets of data contained in a single record accessed by a user would likely require more granular tracking than many audit logs provide, particularly in read-only events where no data is changed. The simpler set of content required for the access report makes the technical feasibility of this proposed requirement much greater than for the accounting of disclosures. This is true even without the flexibility afforded to organizations about providing the name of the person accessing the record, although the NPRM acknowledges that producing the first and last name may require mapping the user ID captured in an audit log to a list of full names. According to the NPRM, allowing for entity-level attribution rather than person-level is intended for situations where organizations outside the entity holding the information are provided access; employees or contractors working for the entity cannot share authentication credentials, as unique user identification is required under the technical safeguards specified in the HIPAA Security Rule (45 CFR §164.312).

One valid criticism regarding the proposed access record provision is that HHS seems to assume that relevant organizations would have only one electronic record system, but hospitals and large health care entities often have multiple systems, so creating the access report would require an aggregation of audit logs or other data drawn from multiple systems, adding cost and complexity to efforts to comply. Given the nature of the data required the technical barrier to producing an integrated view of audit records may not be too great, particularly for organizations that have implemented standards such as the IHE’s Audit Trail and Node Authentication, which include standard formats for audit logs to facilitate integrated audit reporting.

Previous objections to the accounting of disclosure rule often center on covered entities’ prior experience with patients and consumers and the apparent lack of interest by individuals in getting accountings, based on the few historical requests they have received. The implication is that there is a lot of administrative overhead to produce a “product” that for which there is little demand. This argument rings a bit hollow when applied to access records. Accounting of disclosures to date exclude many – perhaps most – occurrences, and only cover external exchanges of data. The access report is focused as much or more on access by insiders, to provide some insight into routine authorized accesses and, more importantly, to indicate instances of inappropriate access by authorized users. There is ample anecdotal evidence to suggest that inappropriate insider access is all too common, although the most well publicized incidents tend to involve abuse of privilege to view celebrity medical records. This type of incident is not limited to health care – recall the State Department contractors who improperly accessed the passport records on the candidates in the 2008 presidential election. In government agencies like the IRS there are formal policies against misuse of authorized access privileges to, for instance, browse tax records, such as Internal Revenue Manual 10.8.34.2, which explicitly forbids users from accessing their own accounts or accounts of friends, relatives, coworkers, other IRS employees, or celebrities. Absent access records, discovery of inappropriate user access must rely on technologies like intrusion detection or auditing systems, and if the latter are in place, it seems a short step to leverage the data already being collected through routine user event monitoring. In large organizations where inappropriate use may be a concern, implementing mechanisms to support data collection needed for access reports under the proposed HIPAA rule – and making employees aware of such data collection – may actually serve as a deterrent to inappropriate behavior.

HHS releases new draft accounting of disclosure rules

The Department of Health and Human Services (HHS) has released a long-anticipated Notice of Proposed Rulemaking that would implement the changes to accounting of disclosures requirements under the HIPAA Privacy Rule. HHS opened a 60-day comment period effective May 31, the date when the NPRM is scheduled to be published in the Federal Register. The changes, specified in the Health Information Technology for Economic and Clinical Health (HITECH) Act, would expand the types of transactions and uses of data that must be include in accountings of disclosures, reduce the time period for which organizations must maintain the disclosure information, and modify the set of information that must be recorded for each disclosure.

Under the current provisions of the HIPAA Privacy Rule, codified at 45 CFR §164.528, covered entities are required to maintain records on disclosures of protected health information for a period of six years, and to furnish that historical record of disclosures (the “accounting”) to individuals who request them. The Privacy Rule included an exemption for disclosures for the purposes of treatment, payment, health care operations, and a variety of other special circumstances, including disclosures to the individual of their own PHI. Collectively, the excepted purposes constitute the vast majority of activity involving disclosure. The current rules also cover all PHI, whether in paper or electronic form. HITECH shortened the accounting period to three years, but removes the exemptions for treatment, payment, and health care operations when the disclosure of information is from an electronic health record (EHR). HHS is also proposing to explicitly list the types of disclosures that are subject to the accounting of disclosure requirement, rather than the prior approach of generally requiring inclusion but enumerating specific exceptions. When the HITECH Act passed, many covered entities expressed concerns about the increased administrative burden they would face by essentially having to track all disclosures rather than the more limited set currently required under the law. Some have also pointed out that many EHR systems currently on the market do not provide the built-in functionality to record the information about each disclosure that is required under the revised rule in HITECH.

As part of the rules promulgated under the “meaningful use” EHR incentive program, the HHS Office of the National Coordinator last year adopted a new standard and EHR certification criterion for recording accounting of disclosure information. When it published its final rule for standards and certification criteria, however, ONC chose to make the accounting of disclosure criterion optional, pending further analysis and discussion on the potential impact of the new requirements to covered entities and business associates. In parallel, HHS issued a request for information in May 2010 seeking input from the industry and other interested parties about the potential burden of complying with the new accounting of disclosure rules, the technical capabilities available in the market to facilitate or automate this process, and evidence about the relative interest among individuals in requesting accountings of disclosures. The new NPRM includes some summary data about the comments received in response to the RFI, perhaps most interestingly noting that a large number of respondents reported no or very few requests for accountings since the Privacy Rule went into effect in 2003.

HHS’ new proposed rule divides individual rights in two, providing for separate rules that give individuals the right to an accounting of disclosures and to an “access report” that, in contrast to disclosures, would provide details about who has electronically accessed the individual’s PHI. The access report provision includes accesses both by employees of covered entities and business associates and by those external to the organization. There is no comparable provision in the current law, but the NPRM notes that since the rule applies only to electronic access, covered entities should already be collecting the relevant information about accesses under practices required in the HIPAA Security Rule. It seems likely that at least part of the justification for this new right is the heightened attention focused on the need for such a record of even routine accesses following a series of well-publicized incidents where hospital employees apparently abused their authorized access by viewing the health records of celebrities or other public figures.

Tiger Team recommends federal PKI cross-certification for all NwHIN participants

In the latest round of security recommendations for the Nationwide Health Information Network (NwHIN), the Privacy and Security Tiger Team (a workgroup of the federal Health IT Policy Committee that advises the National Coordinator for Health IT) offered its proposed approach for issuing digital certificates to NwHIN participants. In a brief presentation given at the Tiger Team’s May 23 meeting, the group recommended that all public key infrastructure certificates used in NwHIN exchanges must comply with Federal Bridge CA standards maintained by the Federal PKI Policy Authority and must be issued only by certificate authorities that have been cross-certified with the Federal PKI framework. The simple rationale for the recommendation offered by Tiger Team members is that any organization, commercial or otherwise, that participates in the NwHIN will presumably need or want to exchange data with federal agencies, and the Department of Veterans Affairs (VA) and other key health agencies have indicated that they will only accept certificates that conform to Federal Bridge CA standards.

Given the leading and central role played by the government in the NwHIN, the Tiger Team’s recommendation seems pretty intuitive. Separate from adhering to standards and expectations maintained by DoD, HHS, VA, and other government health entities, the recommendation — if adopted — would also serve to help realize the vision of getting ONC out of the certificate authority business, and also divest it of some of its governance authority over certificate issuers, who would need to apply directly to FPKIPA to receive cross-certification. Despite the award last summer of a contract to Stanley (now owned by CGI) for infrastructure and operations support that includes managing the digital certificate issuance process, ONC has long made it known that it does not want to operate any long-term infrastructure or own service delivery for the NwHIN. This approach would presumably still leave ONC with the governance responsibility of approving organizations for participation in the NwHIN, so as the NwHIN governance policies and procedures continue to evolve, it will be interesting to see what criteria or evaluation standards may be applied to applicant organizations to determine whether they should be allowed to participate at all. It is also important to remember that, regardless of who issues them, the digital certificates used in the NwHIN bind an organization — not an individual — to the certificate. This means that all employees or contractors of the participating organization who might have authorization to conduct data exchanges with other NwHIN participants are in essence sharing the same identification and authentication credential, putting the onus on the organization to ensure that only authorized individuals can access NwHIN-connected systems and initiate or conduct transactions.

Healthcare entities leary of new government policy extending beyond HIPAA

As the Health IT Policy Committee’s Privacy and Security “Tiger Team” continues its work to provide recommendations and suggested policy guidance on health information exchange, there appears to be some concern among hospitals and other HIPAA-covered entities that the recommendations, if implemented in federal rulemaking, would go add to the security and privacy requirements already in effect under the HIPAA Security Rule and Privacy Rule, and would go beyond the strengthened federal regulations included in the Health Information Technology for Economic and Clinical Health (HITECH) Act. According to a report from Modern Healthcare’s Joseph Conn, a representative of the Federation of American Hospitals raised such concerns during the public comment period of the Health IT Policy Committee’s November 19 meeting. The comments offered at the meeting related specifically to still-pending recommendations on patient privacy and, especially, consent. Previous briefings by Tiger Team leaders have both acknowledged the applicability of HIPAA and other relevant laws in specifying situations in which consent is not required, but in the face of potentially expanded health data sharing through the adoption of electronic health record (EHR) and health information exchange (HIE) systems, committee members have suggested that current regulations do not adequately reflect patient expectations about controlling the use and disclosure of their personal health information, especially when that information is shared via HIE. With so much attention focused on the government’s meaningful use incentive program to encourage EHR technology adoption, the lack (so far) of any privacy provisions in meaningful use rules and standards has prompted Tiger Team discussions about ways to do more to protect patient privacy rights.

During the November 19 meeting, Tiger Team co-chairs Deven McGraw and Paul Egerman presented a set of proposed recommendations for provider authentication in health information exchange, intended in part to address a perceived gap in the HIPAA Security Rule, which requires that HIPAA-covered entities implement policies and procedures to authenticate individual users or entities seeking access to protected health information (45 CFR §164.312(d)), but does not stipulate the means by which such authentication should occur. The Tiger Team advocates mandating the use of digital certificates for entity authentication for all entities involved in health information exchange. Adopting such an approach would require not only the technical capability to implement and use digital certificates among entities participating in HIEs, but also the establishment of a formal process for validating would-be participants (to ensure they are legitimate organizations) and for issuing credentials to approved entities. The authentication model for the Nationwide Health Information Network (NHIN) has long been envisioned to use a single, centralized certificate authority to issue credentials and manage certificate validity, revocation, and related maintenance processes. The most recent recommendations from the Tiger Team suggest that instead of relying on a central authority, the Office of the National Coordinator should establish an accreditation program (perhaps similar to the one used for accrediting EHR testing and certifying bodies under the meaningful use program) to authorize multiple certificate issuers. While a federated or distributed model for credentialing would almost certainly be more scalable than a single-issuer model, there remain unaddressed aspects of governance and oversight related to how ONC can ensure that organizations seeking approval as certificate issuers conform to all relevant technical and governance criteria, and are sufficiently trustworthy to handle entity identity proofing and issue authentication credentials.

Even though some changes to federal health data privacy and security regulations included in HITECH have not yet been implemented, HIPAA remains established law, and additional changes to the provisions in the Security Rule and Privacy Rule cannot be made simply through rulemaking by an executive agency like HHS. While specific changes to the law must be made by the legislature, the Office of the National Coordinator and the HHS Office for Civil Rights generally have the authority to impose additional criteria or specific requirements on HIPAA-covered entities associated with audit standard used to assess compliance, or as conditions for receiving federal funds, whether under meaningful use or one the various federal grant programs intended to promote or expand the adoption of health IT. There seems to be some renewed emphasis on HIPAA compliance, based in part on the expectation that OCR will soon begin to proactively audit covered entities and business associates for compliance with the Security and Privacy Rules. In this environment, it is perhaps understandable that covered entities would object in advance to the prospect of any further changes in the regulatory requirements for which these entities will be held accountable. The fact remains, however, that the law as enacted was not primarily intended to encourage health IT adoption, and if widespread use of such technology is going to be achieved, some of the regulatory areas that leave room for interpretation may need to be augmented with more specific guidance or requirements.

VA over-disclosure of EHR data highlights difficulty in managing fine-grained consent

In its Monthly Report to Congress On Data Incidents for the month of September (the exact time period noted on the report is August 30 - October 3, 2010), the Department of Veterans Affairs (VA) describes an incident in which an active duty member of the Army was determined to be ineligible for deployment based on information contained in a “progress note” recorded at a previous time by a doctor working at a Veterans’ Center where the soldier had been treated. The contents of the progress note were apparently available to doctors at Fort Benning (where the soldier was preparing to deploy), despite the fact that no authorization had been given for the release of the Vet Center information the Department of Defense (DoD). While the specifics of the treatment record were not described, it appears from the incident summary that the information from the Vet Center was transmitted from the VA’s VistA electronic health record (EHR) system to the AHLTA system used by the DoD as a matter of routine procedure, but that the specific information in the progress note should not have been included in the health information transferred from the VA to the DoD. VA Chief Information Officer Roger Baker is cited in an article on the incident as believing that the progress note contents were shared incorrectly because the full contents of the progress note (apparently recorded as a free-text field) aren’t scanned to determine if there is any sensitive information in them for which explicit consent must be obtained prior to disclosure.

The VA is investigating this incident to try to determine exactly how the information in question was transmitted, and whether the fact that it was constitutes a violation of HIPAA or any other relevant health data privacy statutes. The privacy and confidentiality of several specific types of treatment data (including treatment for drug or alcohol abuse and for diseases like HIV and sickle cell anemia) in veteran medical records is protected under 38 U.S.C. §7331, although in general the restrictions on disclosure here do not apply to government “components furnishing health care to veterans and the Armed Forces.” Much of the health data transfer between the VA and the DoD occurs automatically as individuals move among different treatment facilities, and through the bi-directional health information exchange (BHIE) DoD doctors are able to view patient data stored in VA systems (and vice-versa), including progress notes. In this case, while the Army doctor at Fort Benning apparently recalled accessing the soldier’s information through AHLTA, a technical analysis suggested that the DoD system did not access the VA records, so some data sharing method other than BHIE may have been involved.

Quite aside from the technical mechanism that allowed this over-disclosure to occur, this incident highlights the difficulties associated with providing fine-grained control over access to and disclosure of information stored in EHRs. Much of the recent debate over consent in health information exchange has been focused on the consent model to be used, such as opt-in or opt-out. In many ways, handling granularity within a consent management approach is much more complicated than the consent model used. A policy analysis on consumer consent options for electronic health information exchange commissioned by the Office of the National Coordinator and published last March describes several different ways in which fine-grained consent might be applied to data in electronic health records. Many of the ways to sub-divide an individual health record according to patient privacy or sensitivity concerns are not easy to implement within existing EHR systems and schemas, and even if granular consent models are implemented in external policy engines, directories, or databases, to be able to incorporate granular consent by data type, provider, or encounter may require parsing and analyzing the entire electronic health record before any health information exchange request can be fulfilled. Similarly, some of the standard schemas and message constructs recommended for use in health information exchange may by default contain more information than is needed to satisfy a given request. The challenge of restricting health data disclosure according to consent directives is made even more challenging by the use of free-text fields within EHR schemas that, as was seemingly the case with the progress note in the recent VA incident, may knowingly or unknowingly contain information that should be subject to disclosure restrictions.

Rules still pending on privacy and security requirements for PHRs

The Office of the National Coordinator for Health Information Technology (ONC) within the Department of Health and Human Services (HHS) has announced plans for a public roundtable discussion on personal health records (PHRs) to be held in early December. The event will address a variety of aspects related to PHRs and their future direction, and will focus in particular on the topic of privacy and security requirements for PHR vendors and third party providers who are not currently covered by HIPAA. While many HIPAA-covered entities such as health insurance plans and healthcare entities offer some form of personal health record to their customers, vendors like Google (Google Health), Dossia (Personal Health Platform), and Microsoft (HealthVault) do not necessarily fall under the scope of HIPAA, and where they do it is typically only in the role of a business associate. The Health Information Technology for Economic and Clinical Health (HITECH) Act referred specifically to PHR vendors as potentially non-covered entities, and directed HHS, in consultation with the Federal Trade Commission (FTC), “to conduct a study and submit a report on privacy and security requirements for entities that are not covered entities or business associates” (§13424(b)(1)) and to complete that report no later than one year after the law was enacted. The one-year deadline elapsed over six months ago in February, and while work on the report seems to be a higher priority now, ONC Chief Privacy Officer Joy Pritts said recently that she doesn’t anticipate its completion until early 2011.

The original version of the Health Insurance Portability and Accountability Act passed in 1996 mandated compliance with security and privacy requirements only for HIPAA-covered entities, specifically including health care providers, health care plans, and health care clearinghouses. HITECH extended the coverage of the HIPAA Privacy Rule and Security Rule requirements to business associates (whose compliance was previously the responsibility of the covered entity with whom business associate agreements were entered into), and also addressed non-covered entities providing PHRs and associated technical services with some of the provisions in the law. Most notable among these is perhaps the health data breach disclosure and notification rules (§13407) that went into effect in September 2009 (although they remain in the form of “interim rules”). There were two sets of breach disclosure rules put in place — one for covered entities and business associates under the authority of HHS, and the other for data breaches from PHR vendors and other non-covered entities under the authority of the FTC. The section of the HITECH Act that applied the data breach disclosure rule to non-covered entities explicitly includes the word “temporary” in the title, although it is not clear if the expectation was that the rules for privacy and security requirements, when promulgated, would include additional rules on data breach disclosure and therefore supersede the provisions in §13407.

The text of §13424 includes in the scope of the now-overdue study and subsequent report “requirements relating to security, privacy, and notification in the case of a breach of security or privacy” and reflects the same sort of notification exemption language that applies to breaches involving encrypted data (”rendered unusable, unreadable, or indecipherable”). It would seem that the opportunity exists for ONC to revise or make new recommendations regarding data breach disclosures within the context of conducting the study and producing the report that HITECH requires. Of course, a report with recommendations has no force of law, and the scope of rules for non-covered entities that might potentially be promulgated under HITECH’s authority appears limited to handling of data breaches. Potential changes in HIPAA applicability — such as extending it to include currently non-covered entities that nonetheless process, store, or manage health data — would presumably require further legislative action in addition to any executive branch decisions about appropriate privacy and security requirements.

NCHICA offers recommendations to health care providers on security and meaningful use

The North Carolina Healthcare Information and Communications Alliance (NCHICA) just released a white paper entitled “Privacy and Security Implications of Meaningful Use for Health Care Providers” that reflects the results not only of an analysis of federal rules associated with the Electronic Health Record (EHR) Incentive Program administered by the Centers for Medicare and Medicaid Services (CMS), but also of a workshop held last June just before the Sixth Academic Medical Center Security & Privacy Conference. The paper provides a brief background on the “meaningful use” rules that will serve as the basis for health care providers and professionals to qualify for financial incentives to subsidize the cost of acquiring EHR technology, and offers a series of recommendations for health care providers in the areas of governance and compliance, the role of security officers, data exchange and coordinated care, health information exchanges, and patient engagement.

Overall, the NCHICA paper should provide useful high-level guidance to some of the many potentially eligible health care providers who are still trying to make sense of meaningful use. I’ve written fairly extensively on various aspects of this exact topic (including the need for authoritative guidance on conducting risk analyses and the meaningful use security requirements in general), and on balance it seems likely that however prepared or unprepared health care providers may be to comply with meaningful use measures, the requirements associated with security and privacy are not likely to be the most challenging ones to meet, at least for Stage 1 of the program that begins in early 2011. In the interest of full disclosure, please note that ISACA Journal Online just published an article I wrote on essentially the same subject, “Privacy and Security Considerations for EHR Incentives and Meaningful Use” so the NCHICA paper seems to confirm the timeliness and relevance of complying with meaningful use security requirements. Given the protracted federal rulemaking process involved with the meaningful use measures and associated EHR standards and certification criteria, one of the practical difficulties is trying to stay abreast of the specific requirements to which providers will be held accountable while those specifics are undergoing revisions.

As noted above, the contents of the white paper reflect discussions at a pre-conference workshop on privacy and security implications of meaningful use, coordinated by NCHICA and held in early June. At the time this Sixth Academic Medical Center Security & Privacy Conference was held, the final versions of the meaningful use rules and EHR standards and certification criteria had not been published (they were released in mid-July, and published in the Federal Register on July 28), so the material available to workshop participants was from the draft versions released in January. While most of the core themes of the meaningful use program were consistent from the interim to the final versions, some of the items that changed are not reflected in the white paper. For instance, to highlight the central importance of HIEs in the national health IT strategy, the white paper references a passage from the “Meaningful Use Notice Final Rule”, but the quote and its reference are from the proposed (draft) final rule published in January, not the final version published in July. The passage quoted was not included in the final rule, and while the federal funding allocated towards and policy emphasis placed on HIEs certainly speaks to the importance of health information exchanges in general, the final meaningful use rule greatly reduced the focus on the purported benefits to be delivered to health care entities through HIE.

The authors of the white paper point out that the single meaningful use measure related to security is essentially a reference to an existing requirement (under the provisions of the HIPAA Security Rule) to conduct regular risk analyses. Specifically, they explain that “the intent may be broadly interpreted that eligible professionals and eligible hospitals should assess their privacy and security practices in general and make improvements where necessary and appropriate.” This is a much broader interpretation than the guidance offered with the publication of the final rule, which altered the language in the draft meaningful use measure requiring risk analyses so that the final measure explicitly limits the scope of the risk analysis to the certified EHR system or modules being used by the eligible entity.

To their credit, the workshop participants and the white paper’s authors do not limit their focus to Stage 1, but appear to try to consider likely future requirements for Stage 2 and Stage 3, work on which has only just begun. The underlying message is that health care providers need to be taking steps now, both to try to meet existing rules and also to plan for complying with new requirements, including those that will implement provisions in the Health Information Technology for Economic and Clinical Health (HITECH) Act. A further challenge for health care organizations seeking to establish or maintain compliance with all relevant rules is that the EHR incentives program using meaningful use measures and criteria will be in effect before some key HITECH-driven rules are finalized (breach notification) or even drafted (accounting of disclosures). In the case of accounting of disclosure rules, the law gave the HHS Secretary the discretion to delay the implementation of the rules beyond the 2015 deadline for meaningful use Stage 3, so it is far from clear to what extent, if any, providers and professionals will be expected to comply with such legal requirements if the corresponding rules have not yet been promulgated.

When addressing health information exchanges, the white paper suggests that “it will be necessary to re-engineer workflows across organizations, replacing point-to-point connections/interfaces with robust HIE processes.” While it is hard to argue with the position that many-to-many integration patterns are well suited to enabling widespread health information exchange, none of the major federal HIE initiatives provide for any data exchange more complicated than mutually authenticated point-to-point transmissions. Both NHIN Exchange and NHIN Direct rely on entity-to-entity messaging models, although to be fair NHIN Exchange is intended to offer a logically centralized directory (registry) of participating entities, which can be used to satisfy requests from multiple participants to find out which ones have information about specific subjects (such as patients or providers). The integration interfaces that health care entities will use to exchange data in these models may indeed require updating to support multiple data exchange partners, but the communication model is likely to remain point-to-point, and to the extent these HIE participants adopt prevailing HIE standards, little or no entity-specific variation in interfaces should be needed.

The NCHICA authors astutely point to the need for more work to specify patient expectations and requirements with respect to EHRs, HIEs, and health IT in general. They also correctly pinpoint the clinician-to-patient or caregiver-to-patient relationship as the central locus for developing and maintaining patient trust, with a corresponding need to educate and inform clinicians and caregivers of this role with respect to patients. Particularly with respect to trust and EHRs, the paper highlights a suggestion that providers may need assign staff to the role of “patient advocate,” both to help patients understand relevant aspects of the health care system and to foster greater levels of patient engagement or active involvement in their own care.

Health data privacy remains a key factor in slower U.S. adoption of EHRs

A newly released paper by four academic researcher comparing electronic health record adoption in the United States and European Union concludes that concerns over privacy of health record data remain the key obstacle to broader EHR use in the United States. The paper, “Privacy and Security in the Implementation of Health Information Technology (Electronic Health Records): U.S. and EU Compared,” co-authored by Wade Chumney of Georgia Tech, Janine Hiller and Matt McMullen of Virginia Tech, and David Baumer of North Carolina State, assesses the legal privacy protections in place for health information in both the US and EU, and attribute the much greater penetration of EHRs in many European countries (such as Holland, where nearly all residents have EHRs) to the stronger privacy regulations. Specifically, the researchers point to a notable lack of public support for health IT such as EHRs in the United States, and key differences in legal and policy approaches to data privacy in the US and EU, where the American stance is seen as more reactive compared to the EU’s proactive approach. The recommendations in the report include suggestions that US health data privacy laws be strengthened (beyond the impact of HITECH on HIPAA) in areas such as giving a private right of action to individuals who suffer from violations of privacy laws, implying that affording redress rights to individuals would help overcome privacy-driven reluctance about using EHRs. It remains to be seen whether the Department of Health and Human Services’ Office for Civil Rights, has the resources and resolution to follow through on its stated intentions to more vigorously and proactively enforce federal health data privacy and security regulations, and if so, what impact stronger enforcement might have on public perceptions about data privacy in healthcare.

While it’s hard to argue against implementing better protections for health data and stronger enforcement of current privacy laws, greater efforts are also needed to educate consumers (and healthcare providers) about health IT and its capabilities. In a blog post published on Tuesday, MEDecision’s Eric Demers warns that excessive fears about health information privacy threaten to needlessly slow EHR adoption, a situation that could be avoided with a combination of better enforcement of existing legal safeguards like those under HIPAA overseen by HHS’ Office for Civil Rights, and with broader education of consumers about the strength and effectiveness of existing EHR security. When available security mechanisms are actually implemented and configured correctly, it is probably true that the risk of loss of confidentiality or integrity for electronic health record data is commensurate with online retail or banking, as Demers suggests. But if a consumer’s data is stolen in those domains, there is typically very little loss incurred (with the obvious exception of cases where the stolen data enables identity theft), because laws and business practices in e-commerce and banking mean that the businesses shoulder all the financial burden, so the customer is rarely if ever hurt out of pocket. This is not the case for health data, or more importantly perhaps it is not perceived to be the case, as people seem to take think the loss or theft of their medical record data is much more dire than losing some personal financial information. Also, the personal data associated with retail and banking transactions is not nearly as sensitive (to most people) as their health data is — it’s trivially easy to change an account number, get a new credit card, or restore stolen funds. What this may mean is that EHR vendors and health care users of health IT may need to convince people that health data privacy and security protections are more robust or provide better protection than controls in situations with which they are already familiar.

EHR security capabilities can’t help if you don’t use them

An often overlooked aspect of security for electronic health records (EHRs) is that while there are several types of security capabilities that vendors of EHR systems and modules must include in their products in order to get them certified under meaningful use, the organizations acquiring and using these EHRs are not typically required to implement specific security features. This is not a new approach to security in health care, and in fact is logically consistent with most of the security controls specified under HIPAA and FISMA regulations, but the result remains that the decision of what actual security and privacy controls an organization puts in place remains highly subjective and therefore likely to vary greatly among health care entities.

Where security and privacy laws are concerned, Congress has always shown reluctance to mandate specific security measures or technologies, in part to avoid favoring any particular technology or market sector or vendor, and also because the authors of such legislation correctly assume that they may lack the technical expertise necessary to identify the most appropriate solutions, and instead choose to delegate that task to NIST or other authorities. The net result however is sets of “recommended” or “addressable” security safeguards or, in the case of explicitly required security controls, endorsing a risk-based approach to implementing security that allows organizations to choose not to put some controls in place with appropriate justifications for those decisions. There’s nothing inherently wrong with this approach — it embodies fundamental economic principles about security, particularly including the idea that it doesn’t make sense to allocate more resources to securing information and systems than what those assets are worth. The problem lies in the reality that different health care organizations will value their information assets in different ways, will face different threats and corresponding risks to those assets, and will have different tolerances for risk that drive what is “acceptable” and what isn’t, and similarly drive decisions about what security measures to implement and which to leave out.

From a practical standpoint, what might be helpful to build confidence in the security of health IT such as EHR systems would be a set of minimum standards for security that all organizations would need to implement. The HIPAA Security Rule includes a large number of administrative, physical, and technical safeguards (45 CFR §§164.308, 164.310, and 164.312, respectively), but many of the “required” safeguards are described in sufficient vague terms that compliance is possible with widely varying levels of actual security, and many of the most obviously helpful safeguards, like encryption, are “addressable” and therefore not required at all. There were relatively few security standards and criteria included for meaningful use stage 1, and most of the items that were included already appear somewhere in the HIPAA security rule, but what stands out about the standards and criteria is how little specificity they contain. The minor revisions to these security items in the final rules issued late last month should make it fairly easy for organizations to satisfy the measures, but will have little impact in terms of making EHR systems or the health care organizations that use them more secure. The only identifiable “standards” included are government Federal Information Processing Standards (FIPS) for encryption strength (FIPS 140-2) and for secure hashing (FIPS 180-3), while everything else is described in functional terms that leave the details to the vendor providing the EHR system or the entity doing the implementation. Even the risk analysis requirement (the only explicit security measure in meaningful use) was reduced in scope between the interim and final versions of the rules, as under meaningful use the required risk analysis only needs to address the certified EHR technology the organization implements, not the organization overall. This is markedly less than what is already required of HIPAA-covered entities (and, under HITECH, of business associates as well) under the risk analysis provision of the HIPAA Security Rule. The security-related meaningful use measures and associated standards and certification criteria for EHR systems provide another instance of federal rules promulgated under the authority of the Health Information Technology for Clinical and Economic Health (HITECH) Act that, as implemented, fall somewhat short of the vision articulated in the law.

The challenge of sustainability for HIEs

At last week’s National Forum on Health Information Exchange, held by the eHealth Initiative in Washington, DC, a lot of discussion and a panel session centered around the topic of sustainability for HIEs, as many nascent HIE projects try to look beyond the start-up phase to routine operations after federal and state subsidies are not likely to be available. Forum events such as this offer good opportunities to learn about the different approaches being taken, and to compare the similarities in the messages from representatives of HIE initiatives at different levels of maturity or phases of implementation. In theory, the best information on sustainability should come from well-established HIEs such as the not-for-profit HealthBridge, the southern Ohio-based exchange that has been in operation since 1997 and relies for funding largely on hospital systems and other users of its clinical messaging system. For all but government-run models of HIE-as-public-good, a big part of the challenge seems to be how to establish a business model for operating a HIE that provides enough financial incentive for commercial enterprises or public/private partnerships to be viable. Global IT services firm CSC, which operates the New England Health Exchange Network (NEHEN) under contract, believes that NEHEN provides a model by which other exchanges can be successful (ideally of course, with CSC’s expert assistance).

The trick here is to demonstrate sufficient value in the early stages of a HIE’s existence that its users and stakeholders realize real (or the potential for real) benefits from health information exchange. Most agree that it is important to avoid standing up an “empty” HIE — that is, an infrastructure with little or no data available through it — whether the lack of data is due to few organizations participating, a too-narrow scope of intended uses, or an opt-in approach to user consent, which depends on at least some users deciding to allow personal data sharing. For now, the only thing that seems clear is that there isn’t an obvious answer on sustainability in terms of a consensus on a business model, but the diversity among ongoing HIE initiatives should provide a lot of data points on what works and what doesn’t.