Reform Rodeo

1. The Final Push: Kaiser Health News compiles the latest news stories detailing the final push that is underway by Democrats and the White House to try and pass their comprehensive health reform plan.

2. Rep. Paul Ryan: Ezra Klein interviews Republican Rep. Paul Ryan of Wisconsin; the two discuss the economic impact of the Democrats’ health reform plan.

3. Abortion: Tim Jost does a yeoman’s job of laying out the differences between the House and Senate bills regarding abortion funding.

4. Health Summit Redux: Ewe Reinhardt discusses the lessons learned from the Health Summit.

5. Health IT: John Halamka covers the new HITECH-related NPRM that HHS recently released. The newest NPRM deals with the process of certifying EHR systems under the CMS’s incentive-based framework for meaningful EHR use.

6. Health IT Review: For those trying to catch up on health IT developments, Computerworld has a critical yet thorough account of the high speed push towards EHR adoption.

7. Isn’t That Nice:  A feel good story about the The Oracle of Omaha  and Dr. Atul Gawande.

Things You Wanted to Know About the New HIT Standards But Were Too Afraid to Ask

In a previous post I discussed the interim final rule (IFR) that was recently promulgated by the Office of the National Coordinator for Health Information Technology (ONC).  The previous post discussed two of the four categories of standards in the IFR. This post will look at the final two categories. In order to appreciate the purpose of the final two standards, it is worth recapitulating the basic framework upon which the IFR is based.

The ONC’s framework for the standards is to first start with the meaningful use objectives. From the broad objectives of meaningful use, the ONC establishes certification criteria for these objectives. Based on the certification criteria, the ONC has adopted standards that would allow for an objective determination of whether the criteria has been met.

An example will help: One of the meaningful use objectives is “the capability to exchange key clinical information among providers of care and patient authorized entities electronically.”  To achieve this objective, “Certified EHRs” will have to meet the following criteria: “[The EHR system must] electronically receive a patient summary record, from other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, immunizations, and procedures and upon receipt of a patient summary record formatted in an alternative standard specified in Table 2A row 1, displaying it in human readable format.”

In order to guide EHR vendors (and purchasers) in fulfilling the above criteria–and likewise the larger meaningful use objective–the ONC has adopted a number of standards that EHRs must utilize in order to be certified. These standards fall into 4 general categories.

1. Vocabulary Standards — The standardized nomenclatures and code sets used to describe clinical problems and procedures, medications and allergies.
2. Content Exchange Standards –  The standards used to share clinical information such as clinical summaries, prescriptions, and structured electronic documents.
3. Transport Standards — The standards used to establish a common, predictable, secure communication protocol between systems.
4. Privacy and Security Standards — Standards relating to authentication, access control, transmission security which relate to and span across all of the other types of standards.

My previous post provided a general overview of the first two standards, the first of which specifies the language of “EHR speak,” while the second specifies standards giving that EHR vocabulary a predictable organization so as to ensure that different EHR systems can interpret the data.

In the previous post I used the analogy of the Bluebook style of citation to explain the content exchange standard and vocabulary standard. As you can see, the following two citations share the same basic organization (e.g. case name in italics, followed by the reporter volume number, name of the reporter, starting page of case, etc).

Wilson v. Mar. Overseas Corp., 150 F.3d 1 (1st Cir. 1998)

Orange County Agric. Soc’y, Inc. v. Comm’r, 893 F.2d 529 (2d Cir. 1990).

The content exchange standard is analogous to the order of the different elements of the citation. Regardless of the case, all Bluebook citations to federal court of appeals cases have this same basic organization. The part that changes is the vocabulary. As you can see in the cases above, two different reporters (publishers) have been used: F.3d and F.2d.  There are still only limited options for the vocabulary of court reporters.  Likewise, even though the organization of a patient’s record will remain constant, it will obviously consist of different terms depending on, among other things, the patient’s diagnosis and test results. The possible terms within the chart are determined by the vocabulary standards.

Essentially, the signifier and syntax standards are meant to save us from constructing a costly high-tech Tower of Babel. A sign (word, letter, number, symbol) displayed in a particular way must have an agreed to and discernible meaning.

With these two standards in mind, a brief overview of the latter two standards is possible.

Transport Standards

Though the data is sitting on server A in a structured format–governed by the content exchange and vocabulary standards discussed above–there is more that needs to occur for the data to be useful. For example, Computer A must “know” how to send a request for that data in a way that Computer B can understand. Likewise, Computer B must “know” how to respond to Computer A’s request, i.e., how to structure the response it will give to Computer A. This is where the third category of “transport standards” becomes important.

Luckily for us, one of the transport standards (SOAP) adopted by the ONC is the same standard used by LexisNexis. This allows us to continue our analogy.

When I log onto LexisNexis, I have the opportunity to enter a citation. The citation must be entered in the same basic order that the Bluebook citation provides. Therefore, utilizing the first case cited above, I would type in:

150 F.3d 1

The name of the parties in the case is not necessary since only one case occurs at a given page (page 1) of a reporter’s (F.3d) volume (150). If I submit that citation and Lexis recognizes it, Lexis will then display the case. The beautiful thing about Lexis (and Westlaw) is that the case data, like the citations, has a specified organization–analogous to the organization specified by content exchange standards. One discrete element common to all Lexis cases is a field listing the parties’ counsel. Let’s say that I am an iPhone application developer and I want to create a simple application that would allow a user with a Lexis account to type in a citation like the one above, and in response the program would output the opposing counsel field (as opposed to the whole case). My application would need to know how to trigger Lexis’s server to go and find that information in the database. Likewise, the Lexis database must know how to package and send that data back to the client application. Thus, the fact that Lexis organizes data like citations and counsel into organized fields with specific vocabulary is not sufficient. Rather, there must be a standard governing the requests of specific information, as well as how that information should be formatted and transmitted. This is the role of the “transport standards.”

The ONC adopted two alternative standards–the SOAP standard and the REST standard–to govern requests and responses between client and server computers. As stated above, the SOAP standard is used by Lexis (and other Internet sites) to allow other applications and services to be able to interact with it. That Lexis uses the same standard as that adopted in the HIT interim final rule helps to illustrate the broad nature of  transport standards. Unlike the content exchange and vocabulary standards that are unique to the practice of health care, the transport standards ensure that services wishing to interact with a server have an agreed upon framework by which to accomplish the interaction.  As becomes obvious from this discussion, ensuring the proper implementation of the transport standards is critical to meeting the meaningful use objective described earlier that dealt with exchanging clinical information among providers. Additionally, having a specified standard for requesting and receiving the data is crucial for personal health record (PHR) services that seek to interface with the databases of health care providers in order to retrieve and display certain information to the consumer of the PHR.

Privacy and Security Standards

The fourth group of standards deals with privacy and security, and for the most part, this part of the IFR is straightforward. The reason for the straightforwardness is that the ONC has decided to model their privacy and security criteria off of HIPAA’s Privacy and Security Rules. Therefore, there are no real surprises. With that said, the HITECH Act does direct the various HIT committees as well as the ONC to look at capabilities beyond those specified in the HIPAA Security Rule. Thus, even though the IFR does not change the privacy and security landscape in any major way, there is no promise that things won’t change in the future.

Specifically,  the ONC has adopted standards for certain aspects of HIPAA but not others. For example, standards have been adopted for the encryption of data, but not for “access control” measures that are used to prevent unauthorized access at computer terminals connected to EHR systems. The ONC’s rationale is that the methods of regulating access are evolving at a rapid pace, whereas there are industry best practices available for encrypting information. As a result, the ONC requires all certified EHR systems to be capable of encrypting their data. This is somewhat remarkable given that HIPAA and HITECH do not require all entities to use encryption. The ONC believes that this capability will spur the use of encryption by making it available to all consumers of certified EHR systems. Furthermore, the implementation of encryption by HIPAA covered entities is important because it acts as a safe harbor, relieving them of the responsibility of having to report a data breach.

As Table 2B shows, the ONC distinguishes between the general encryption of stored data on the one hand and the encryption of transmitted data on the other hand. Please click on the thumbnail below to enlarge the table.

The ONC has stated numerous times that the IFR in no way changes the responsibilities of covered entities or business associates under HIPAA (and HITECH). Rather, it solely concerns the capabilities of certified EHR systems.

An Overview of the New Federal Standards Governing Health Information Technology (Part 1)

Those hoping for health reform have recently had a bad stretch of luck. I am here to report that movement in the reform process is certain in one area: health information technology (HIT). It may not be the sexiest topic in health care, but as David Blumental, the director of the Office of the National Coordinator for Health Information Technology (ONC),  noted in his piece for the New England Journal of Medicine, “[i]nformation is the lifeblood of modern medicine. Health information technology (HIT) is destined to be its circulatory system.” The ONC recently released an interim final rule (IFR) for HIT standards. CMS released a notice of proposed rule making (NPRM) that describes how Electronic Health Records (EHRs) are to be put to “meaningful use.” The context of both of these rules is the incentive-based program that the federal government has created. The goal of this program is to spur the creation of a sustainable and interoperable nationwide network of EHRs.

As opposed to describing every detail of the ONC’s interim final rule, I think it would be more valuable to broadly discuss the general standards that the government has decided upon, and then describe those standards so that the reader has a general idea of what these standards are.

Two Tables are Primary Reference for Understanding the Rule

So what did the ONC determine? The easiest way to tease out the big picture is to refer to two tables (Table 1 and Table 2A) that are buried within the IFR.

The two tables have been extracted from the pdf for ease of reference. Table 1 can be found here (pdf). Table 2A can be found here (pdf).

For the full IFR, it can be found here in pdf or here in html.

Using the tables to decode the IFR

Table 1 has three columns. The column on the left consists of the stage 1 meaningful use objectives that were issued by CMS and which serve to govern the purpose and capabilities of EHRs at a broad level. (For background on CMS’s proposed guidelines for meaningful use, see my earlier post here). The two columns on the right of Table 1 are the ONC’s certification criteria. These criteria have been created in order to support CMS’s meaningful use objectives. The middle column corresponds to the criteria for non-hospital providers–referred to as eligible professionals–such non-hospital-based physicians. The rightmost column corresponds to the criteria for hospitals (referred to as eligible hospitals). These two groups, eligible professionals and eligible hospitals, are eligible in the sense that they are eligible for reimbursement in exchange for the meaningful use of EHR technology.

Table 2 is the final piece of the puzzle, laying out the standards that the ONC has adopted. The standards are the nitty gritty details of the broader certification criteria that support the even broader meaningful use objectives.  Thus, we have a framework for our standards: start with the meaningful use objectives, establish certification criteria for these objectives, and then specify the standards that would allow for an objective determination of whether the criteria has been met.

With these tables in hand, it is possible to delve a bit deeper into the ONC’s vision of HIT.

Three Important Phrases: “Certified EHR Technology”, “Complete EHR”, and “EHR Module”

The regulations utilize the phrases “Certified EHR Technology”, “Complete EHR,” and “EHR Module” in an effort to implement flexible standards that can evolve as the standards continue to evolve. This idea of the rules evolving is a common theme, and it cannot be stressed enough that the ONC has gone through great pains in balancing the predictability of constrained EHR standards with the dynamism of the evolving standards landscape.

Terms

• Qualified EHR: an electronic record of health-related information on an individual that:
  • (A) Includes patient demographic and clinical health information, such as medical history and problem lists; and
  • (B) has the capacity:
    • (i) To provide clinical decision support;
    • (ii) to support physician order entry;
    • (iii) to capture and query information relevant to health care quality; and
    • (iv) to exchange electronic health information with, and integrate such information from, other sources.’
• Certified EHR Technology: A Complete EHR or a combination of EHR Modules, each of which:
  1. Meets the requirements included in the definition of a Qualified EHR; and
  2. has been tested and certified in accordance with the certification program established by the National Coordinator as having met all applicable certification criteria adopted by the Secretary.
• Complete EHR: EHR technology that has been developed to meet all applicable certification criteria adopted by the Secretary.
• EHR Module:  any service, component, or combination thereof that can meet the requirements of at least one certification criterion adopted by the Secretary. Examples:  Interface or other software program that provides the capability to exchange electronic health information; An open source software program that enables individuals online access to certain health information maintained by EHR technology; A clinical decision support rules engine; A software program used to submit public health information to public health authorities; and, A quality measure reporting service or software program.

In order to allow for flexibility, the ONC does not require that “Certified EHR technology” is a complete “turn key” system. Rather, the ONC allows for two different types of “Certified EHR Technology.” On the one hand you have “Complete EHRs” which are  “turn key” solutions in that a complete EHR meets the broad functional requirements of a qualified EHR and all of the  certification criteria listed in Table 1 (see link to Table 1 pdf above). On the other hand, “Certified EHR Technology” may also consist of a combination of modules, as long as the combination of modules meets the broad functional requirements of a “Qualified EHR,” and the modules together satisfy all of the certification criteria. Thus, physicians and hospitals retain flexibility in how they implement technology to achieve meaningful use.

The Adopted Standards

The ONC has grouped the standards into four groups:

1. Vocabulary Standards — The standardized nomenclatures and code sets used to describe clinical problems and procedures, medications and allergies.
2. Content Exchange Standards –  The standards used to share clinical information such as clinical summaries, prescriptions, and structured electronic documents.
3. Transport Standards — The standards used to establish a common, predictable, secure communication protocol between systems.
4. Privacy and Security Standards — Standards relating to authentication, access control, transmission security which relate to and span across all of the other types of standards.

Content Exchange Standards

Table 2A describes the first 2 categories. It is actually most helpful to initially discuss the second category: the content exchange standards. The content exchange standard can be thought of as the rules that constrain the shape and form of the data. In other words, it concerns how the data is structured. A standardization  of the structure is necessary so that different computer systems can predictably send and receive data that is organized in a predictable format. A rough analogy can be made to the Bluebook citation standards which specify the organization of legal citations. Regardless of the court reporter being used, all bluebook citations to federal court cases have the same basic organization (e.g. case name in italics, followed by the reporter, starting page, etc). Whereas a law school journal may only accept the Bluebook standard, the ONC has decided to allow for two standards:  Health Level Seven (HL7) Clinical Document Architecture (CDA) Release 2 (R2) Level 2 CCD or ASTM CCR.  Again, the ONC has sought flexibility in the initial stage of the certification process by allowing for multiple standards to be used. As noted in Table 2A, the ONC will eventually decide on one of these standards. It should be noted that if HL7 is picked, the ASTM standard can be “mapped” onto HL7 so that systems using ASTM can become interoperable with HL7-based systems.

The first standard is referred to as HL7 CDA R2 CCD. Though the name is intimidating, it is not very difficult to explain. HL7 is an international health care standards organization. The Clinical Data Architecture part of the name serves to identify that we are dealing with HL7’s standards regarding the organization of clinical documents that are sent and received electronically. It is necessary to specify CDA because HL7 has released other standards. The R2 refers to the fact that it is a second version of the standard. The CCD stands for Continuity of Care Document, and identifies that the standard deals with a constrained amount of health information–specifically, the information necessary to create a summary of a patient’s medical history.

Vocabulary Standards

To go back to the Bluebook analogy, the Bluebook must do more than specify the organization of the information in a citation. Additionally, it must specify the actual content that can be represented. For example,  the vocabulary of the reporter of a federal appeals case consists of F. or F.2d or F. 3d. Likewise, the vocabulary of EHRs must be standardized. The standards adopted for the vocabulary are listed in Table 2A.  There are a variety of different standards that have been adopted, including ICD-9, SNOMED, and LOINC. Some of these standards are in competition, and as Table 2A shows, the ONC’s position on competing standards will change in Stage 2 of Meaningful Use. For example, the vocabulary for medications will become more restrictive in Stage 2. However, some standards are not in competition, but are independent and describe wholly different aspects of medicine. For example, RxNorm describes medications but says nothing about laboratory test results, which is the domain of the LOINC vocabulary.

Hopefully the above discussion of the ONC’s adopted standards offers a foundation that allows for closer inspection of the IFR. The second part in this series will detail the two additional categories of standards, as well as other salient details of the IFR.

For additional information on the ONC’s rules, the following resources may be of interest:

The ONC’s most recent meeting, including mp3s of the meeting, can be found here.

General information about the ONC’s efforts with respect to the new standards can be found here.

Information about Clinical Data Architecture can be found here.

A solid overview of the new standards can be found here.

CMS and HHS Release New Proposed Rules Governing Health IT – Part 1: Overview of Proposed Rule on “Meaningful Use”

Issues surrounding the implementation of health information technology (HIT) have not garnered anywhere near the amount of attention as issues such as the public plan, the intersection of abortion and health insurance, pre-existing condition provisions, etc. There are a variety of reasons for this.

First, HIT is not as accessible as these other issues. Discussions of HIT often involve the heavy use of acronyms as well as technical jargon that can be intimidating and confusing. This will not likely change in the future. HIT will increase in complexity, especially as variegated computer systems used by providers and hospitals are to be linked together.

A second reason for the lack of coverage of HIT is that there have been few if any significant steps on the federal level towards implementing a national HIT system. As I will discuss below, this is beginning to change, and this change provides for an important New Year’s resolution that all of those interested in health policy should make: stay informed about the changes in the HIT landscape. To make this resolution easier, I will write a series of posts describing the changes.

One of the more recent changes occurred with the passing of the American Recovery and Reinvestment Act (ARRA), and more specifically, portions known as the Health Information Technology and Clinical Health Act (HITECH Act). The HITECH Act initiated, among other things, an incentive-driven paradigm for transforming our health information system. The general idea is that physicians and hospitals will be paid for using HIT. However, in order for this transformation to take place, guidelines must exist such that physicians, providers and vendors of HIT products understand how to operate within this new system.

On December 30^th 2009, CMS and the Office of the National Coordinator of Health and Human Services (ONC), released two rules. ONC released an interim final rule regarding the standards that will govern the Medicare and Medicaid incentive program. Additionally, CMS released their proposed rule on what is considered meaningful use.

The interim final rule regarding the standards can be found here.

The proposed rule regarding meaningful use can be found here.

Meaningful Use

CMS’s proposed rule on meaningful use is important because it defines how physicians and providers must implement HIT in order to qualify for CMS’s incentive payments for the use of such technology.  Much of the proposed rule is based on the HIT Policy Committee’s proposals on Meaningful Use, but comments had been solicited and incorporated from other committees, HIT vendors, and providers. The proposed rule states that incentive payments will begin in 2011, and that there will be two different payment methodologies: one for Medicare and one for Medicaid. Those receiving incentives must choose either the Medicaid or the Medicare plan. Furthermore, the rule states that hospitals and providers that are not meaningfully using HIT will have their payments from Medicare reduced, with the reductions taking effect in 2015.

The HITECH Act amended the Social Security Act, and in doing so, incorporated a broad definition of what constitutes a meaningful user of Electronic Health Records (EHR). Specifically for a provider to be a meaningful user they must:

1. Demonstrate use of certified EHR technology in a meaningful manner;
2. Demonstrate to the satisfaction of the Secretary that certified EHR technology is connected in a manner that provides for the electronic exchange of health information to improve the quality of health care such as promoting care coordination, in accordance with all laws and standards applicable to the exchange of information; and
3. Use its certified EHR technology, submits to the Secretary, in a form and manner specified by the Secretary, information on clinical quality measures and other measures specified by the Secretary.

The proposed rule is an extension of this definition, and aims to provide those EPs and hospitals with the proper information to become a meaningful user.

Specifically, the rule provides for two classes of providers to participate in the incentive system: eligible professionals (EPs) and hospitals.  EPs are defined as non-hospital-based physicians, who either receive reimbursement for services under the Medicare Fee-For-Service program (FFS) or have an employment or contractual relationship with a qualifying Medicare Advantage organization (MA); or healthcare professionals meeting other requirements. (See page 22 of PDF). Hospitals are defined as hospitals that either receive reimbursement for services under the Medicare FFS program or are affiliated with a qualifying MA organization as described in section 1853(m)(2) of the Act; critical access hospitals (CAHs); or acute care or children’s hospitals. (See page 22 of PDF).

Transitioning to the meaningful use of EHRs will be phased in, taking place in three stages. On page 40 of the proposed rule, CMS describes the stages as follows:

Stage 1 (beginning in 2011):  The Stage 1 meaningful use criteria focuses on electronically capturing health information in a coded format; using that information to track key clinical conditions and communicating that information for care coordination purposes (whether that information is structured or unstructured, but in structured format whenever feasible); consistent with other provisions of Medicare and Medicaid law, implementing clinical decision support tools to facilitate disease and medication management; and reporting clinical quality measures and public health information.

Stage 2: Stage 2 expands upon Stage 1 to use HIT for continuous quality improvement at the point of care and the exchange of information in the most structure format possible, such as the electronic transmission of orders entered using computerized provider order entry (CPOE) and the electronic transmission of diagnostic test results such as blood tests and nuclear imaging tests.

Stage 3: Stage 3 focuses on improving the quality, safety, and efficiency of health care, focusing on decision support for national high priority conditions, patient access to self-management tools, access to comprehensive patient data, and improving public health.

The proposed rule that was recently released only describes the specific criteria for Stage 1, with the criteria for Stage 2 and Stage 3 to be released at the end of 2011 and 2013 respectively. In terms of Stage 1 criteria, there is a hierarchy of organizational structure. At the broadest level there are “health outcome policy priorities.” Within each of these policy priorities there is a group of “care goals,” and associated with each group of care goals are the specific “objectives.” CMS has provided a very helpful table which breaks down the hierarchy, including the various objectives. I have extracted the table, which can be accessed here. However, for reference purposes, I have summarized the organization below, and provided the objectives for the first health policy priority. Note that there is a different list of objectives for hospitals, many of which are similar or identical.

The organization is as follows:

Health Outcome Policy Priority 1: Improving quality, safety, efficiency and reducing health disparities.

Care Goals: 1. Provide access to comprehensive patient health data for patient’s healthcare team 2. Use evidence-based order sets and computerized provider order entry (CPOE) 3. Apply clinical decision support at the point of care 4. Generate lists of patients who need care and use them to reach out+ to those patients. 5. Report information for quality improvement and public reporting.

Objectives for Eligible Professionals (EPs): 1. Use Computerized Physician Order Entry (CPOE) 2. Implement drug-drug, drug-allergy, drug-formulary checks. 3. Maintain an up-to-date problem list of current and active diagnoses based on ICD-9-CM or SNOMED CT®. 4. Generate and transmit permissible prescriptions electronically (eRx). 5. Maintain active medication list. 6. Maintain active medication allergy list. 7. Record demographics 8. Record and chart changes in the following vital signs 9. Record smoking status for patients 13 years old or older. 10. Incorporate clinical lab-test results into EHR as structured data. 11. Generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research, and outreach. 12. Report ambulatory quality measures to CMS (or, for EPs seeking the Medicaid incentive payment, the States) 13. Send reminders to patients per patient preference for preventive/follow-up care. 14. Implement five clinical decision support rules relevant to specialty or high clinical priority, including for diagnostic test ordering, along with the ability to track compliance with those rules. 15. Check insurance eligibility electronically from public and private payers. 16. Submit claims electronically to public and private payers.

Health Outcome Policy Priority 2: Engaging patients and families in their healthcare

1. Care Goal 1: Provide patients and families with timely access to data, knowledge, and tools to make informed decisions.

Health Outcome Policy Priority 3: Improving care coordination

1. Care Goal 1: Exchange meaningful clinical information among professional health care team.

Interestingly, for CPOE, EPs are required to use CPOE for at least 80 percent of all orders whereas hospitals are only required to use CPOE for 10 percent of orders. Why such a discrepancy exists is presently unclear.

In terms of the requirement for reporting clinical quality measures (as described in the original definition of meaningful use in the HITECH Act), the proposed rule adopts different measurements for EPs and hospitals. For EPs, the proposed rule utilizes the quality measures endorsed by the National Quality Forum (NQF) including selected for the Physician Quality Reporting Initiative (PQRI) program that had previously been endorsed by the NQF. For hospitals, the measures are a combination of the NQF measures and those measures from the Reporting Hospital Quality Data for Annual Payment Update (RHQDAPU).

Reporting of these clinical quality measures would be accomplished by one of three methods. The primary method would require EPs or hospitals to log onto a CMS-designated portal and upload the clinical quality data in a specific data structure (as defined by the ONC’s standards). Alternatively, data could be submitted through a Health Information Exchange(HIE)/Health Information Organization (HIO) depending on whether the Secretary can access that network. Another alternative is submission through registries dependent upon the development of the necessary capacity and infrastructure to do so using certified EHRs. See page 169 of the PDF for more details on the uploading process.

As discussed earlier on this blog, one aspect of the transition that remains to be addressed is whether the incentives provided to EPs and hospitals will be sufficient to encourage physicians to take on the initial outlays associated with EHRs. H.R. 3014 ,a bill to provide loans guarantees to solo and small group practices, has been passed by the House and is currently being reviewed by the Senate Committee on  Small Business and Entrepreneurship. Without such measures to spur the initial implementation of EHRs, the incentives or downward payment adjustments may not be sufficient to implement the bold plan set out by CMS.

HIPAA, The HITECH Act, and How Google May Still Be Able to Distribute, and Profit From, Your Personal Health Info

Below I will explore what seems to be a gaping hole in the HITECH Act. However, as with any new legislation, it is often necessary to reexamine the laws that preceded it, which in this case is HIPAA.  This is particularly true given that the HITECH Act does not replace HIPAA. Rather, it provides–amongst other things–additional security and privacy safeguards with respect to health information. To that extent,  at least a cursory reexamination of HIPAA is required before understanding HITECH and the importance of comprehensive legislation.

HIPAA was a product of the 1990’s–an era triggering nostalgic memories of grunge music  for some, and the (in)famous Macarena dance for others. For a large part of this period, the Internet was accessed by a handful of tech savvy individuals who dialed into services like CompuServ, Prodigy, and AOL.  It was during this transition that Congress felt the need to make health insurance more portable, as well as standardize the variegated electronic systems that were conducting nonstandard healthcare-related transactions. There was a concomitant concern that health information needed better protection. Thus, in 1996 Congress adopted the Health Insurance Portability and Accountability Act (HIPAA), providing HHS with the responsibility to enforce it. However, the regulation enforcing privacy and security of health information would not be implemented until years later.

HIPAA’s Privacy Rule, which describes the appropriate use and disclosure of certain health information, came into force on April 14th, 2001, updated in 2002, with compliance required by April of 2003. The Security Rule, which establishes the policies and best practices for securing health information, came into force in 2003. Thus, the Privacy and Security Rules (referred to below as HIPAA) came to life in a period of technological transition. New technologies like residential broadband Internet access and Wi-Fi networks were becoming the norm. Electronic Health Record (EHR) systems had been developed, but had only marginal penetration within certain academic medical centers and government entities. Consequently, the threats to patient privacy from early EHRs was much smaller than it is today, since these systems were not widespread and did not often share data over disparate regions. Thus, access to the systems was not necessarily available outside of the intranets where the servers were located.

Acronyms of HIPAA & HITECH

Acronym	Phrase	General Definition (see 160.103 for regulatory language)
PHI	Protected Health Information	Any oral or recorded information relating to any past, present, or future physical or mental health of an individual, provision of healthcare to the individual, or the payment for the healthcare of that individual.
CE	Covered Entity	A group of entities whose use, disclosure, and protection of PHI is regulated by HIPAA and HITECH. CEs are comprised of: 1) Health care provider (e.g. physicians) that submit transactions electronically. 2) Health care plans (e.g. HMOs) 3) Health care clearinghouses (which are public or private entities, including a billing service, repricing company, community health management information system, etc… that processes or facilitates the processing of health information received from another entity in nonstandard form into standard form, or from standard form to non-standard form.
BA	Business Associate	Individuals or organizations performing an activity involving the use or disclosure of PHI on behalf of the CE. BAs can include attorneys, accountants, shredding companies, billing companies, or any other person or organization that is not a CE but which is accessing a CE’s PHI.
EHR	Electronic Health Record	An electronic record of patient care comprised of information about the delivery of care, including demographic information, medications, diagnoses, etc.
PHR	Personal Health Record	An electronic record of patient care comprised of much of the same information that an EHR is comprised of, but which is created and maintained by the individual (usually a patient) as opposed to a provider. Prominent examples are Google Health and Microsoft HealthVault

d

Given the historical context of HIPAA’s passage, it is easy to appreciate HIPAA’s missteps in not specifically  focusing on EHRs or PHRs.  Rather, HIPAA regulates protected health information at a broader level, focusing primarily on the “use and disclosure” of PHI by CEs, and the best practices and policies for securing the PHI itself.   To be fair, the Security Rule does focus on PHI that is stored and transmitted electronically. However, even the most stringent best practices and policies are useless if the corresponding privacy regulations are inadequate.

But the times they are a-changin’–sort of.

Buried on page 112 of the American Recovery and Reinvestment Act (ARRA)–also known as the Stimulus Bill–is Title VIII of the bill, known as the Health Information Technology for Economic and Clinical Health Act, or more commonly, the HITECH Act. One (of the many) purposes of the HITECH Act is to fill in the gaps that have emerged since the Privacy and Security rules came into force.  But like before, we are in a transition period. Whereas HIPAA’s passage coincided with a period of generalized transition towards digital information, HITECH has coincided with its own transition: the implementation of personal health records (PHRs). Unfortunately, the current HITECH Bill and regulations have serious flaws in how they protect patient information stored in PHRs. However, before discussing the problems, it is only fair to discuss the benefits to privacy and security that HITECH’s passage has provided.

Specifically, HITECH introduces breach notification requirements. HITECH’s provisions govern the procedures which CEs and BAs must follow if health information has been compromised. HITECH also empowers the FTC to promulgate regulations pertaining to the notification procedures of PHR vendors (as well as those who offer services to PHR vendors). The FTC’s proposed breach notification requirements can be found here. Thus, CEs, BAs, and PHR vendors are, for the first time, required by law to notify individuals if their unsecured PHI has been accessed by unauthorized individuals.  Surprisingly, this was not required under HIPAA. CEs were obligated to notify individuals only insofar as the CEs were required by HIPAA to mitigate damages. But now, with the passage of HITECH, breach notification is no longer amorphous, but is spelled out in detail in HITECH’s regulations.

Additionally, HITECH requires BAs to abide by many of the same privacy and security requirements that CEs have had to abide by. Before HITECH, a BA, such as an attorney reviewing the PHI of a CE, was required to sign an agreement promising to protect the PHI that they were accessing, but were not themselves regulated by HIPAA. Thus, BAs had only contractual liability to the CE if the BA violated the rules of the agreement. On the other hand, if a CE violated HIPAA, it was subject to specific penalties and fines by the government.

Under HITECH, BAs must now comply with much of the Privacy and Security Rule, and face many of the same penalties and fines if they violate HIPAA regulations. That is, BAs are now accountable to the government if they improperly use or disclose PHI, or fail to adequately secure PHI.

HITECH also offers other benefits, such as increased enforcement of violations, a strengthening of the requirement that only the minimum necessary information is disclosed to other CEs or BAs, a more thorough framework of accounting for uses and disclosures, as well as a certain prohibitions on the sale of PHI.

The last benefit of HITECH–the prohibition on the sale of PHI–is a perfect springboard for discussing the potential pitfalls of HITECH. The benefits of HITECH may well be sufficient to shore up HIPAA’s gaps when it comes to regulating CEs and BAs. However, as HITECH’s regulatory language makes clear, there remains a gaping hole:

(d) Prohibition on Sale of Electronic Health Records or Protected Health Information-

(1) IN GENERAL- Except as provided in paragraph (2), a covered entity or business associate shall not directly or indirectly receive remuneration in exchange for any protected health information of an individual unless the covered entity obtained from the individual, in accordance with section 164.508 of title 45, Code of Federal Regulations, a valid authorization

The emphasis is added to underscore that PHRs are not included in this provision. There is no corresponding provisions in the FTC’s proposed regulations which concern breach notification. The upshot of this is that, as of the date of this posting, PHR services like Google Health and Microsoft HealthVault are not subject to this prohibition, nor is there a provision in HITECH mandating that PHRs comply with HIPAA’s Privacy and Security Rule. Therefore, PHR vendors can use, disclose–and possibly even sell–an individual’s health information outside of the HIPAA and HITECH regulations. This problem underscores a larger issue: PHRs are not regulated by HIPAA, and only regulated by HITECH insofar as the FTC’s interim rule requires certain breach notification procedures. Read more