Compliance Today - October 2020

The road traveled

Industry participants from the federal government and private sector who believed that digitizing healthcare information is key to improving patient care and reducing the cost of that care set the US healthcare industry on a journey. They envision a world where an individual’s health information flows freely between patient, provider, payer, researcher, and regulator. They theorized that improved care would come from providers and patients having the information required to make appropriate diagnoses and treatment decisions. Cost savings, they hypothesized, would come not just from the reduced friction in the flow of information, but also from visibility into the cost of care and the opening up of the healthcare market to increased competition.

This theory likely had its origins in the late 1960s or early 1970s, when healthcare organizations started adopting clinical information systems and what became known as electronic health records (EHR).^[7] During the 1980s, standards for electronic health information and standards bodies such as Health Level Seven International began to emerge. These systems and standards, it was thought, held tremendous promise for reducing the cost of maintaining health information and improving its accessibility.

It wasn’t until 1996, however, and the passing of the Health Insurance Portability and Accountability Act (HIPAA)^[8] that we saw legislation supporting the flow of electronic healthcare information. Wisely, at that time, there was also a recognition that the digitization of health information would create new risks to the privacy and security of that information.^[9]

The resulting HIPAA Privacy Rule^[10] went into effect in 2003 with its definition of protected health information, followed in 2005 by the HIPAA Security Rule,^[11] requiring management of the risk to the confidentiality, integrity, and availability of electronic protected health information. In 2006, the Enforcement Rule^[12] was introduced, allowing the HHS Office for Civil Rights to impose civil monetary penalties on organizations for violations of HIPAA and to refer offenders to the Department of Justice for potential criminal violations when appropriate.

History shows that despite the emergence of EHRs, electronic health information standards, and HIPAA, the adoption of health information technology (IT) was slow—at least too slow by federal government standards. As a result, 2009 saw the passage of the American Recovery and Reinvestment Act^[13] with the included Health Information Technology for Economic and Clinical Health Act (HITECH).^[14] HITECH brought with it both carrots and sticks.

The HITECH Act created the ONC, which created a healthcare IT certification program. CMS then began providing incentive payments to qualified healthcare professionals and hospitals for the meaningful use of the ONC-certified EHRs. By 2018, the payments totaled more than $38 billion.^[15]

HITECH Act made other course corrections as well. It created a right for patients and third parties they designate to obtain their health information in an electronic format from providers who adopted a certified EHR. It expanded the application of the HIPAA Privacy and Security rules to business associates. But perhaps most importantly, it started Office for Civil Rights enforcement of the HIPAA Security Rule, which resulted in the HIPAA Breach Notification Rule^[16] implementing breach reporting requirements, increasing enforcement, and increasing potential legal liability for HIPAA violations.

2010 saw the passage of the Affordable Care Act.^[17] Primarily focused on making health insurance more available and affordable, the Affordable Care Act also included funding for grants focused on providing better care at a reduced cost. One recipient of such an award was SMART Health IT.^[18] SMART Health IT is a project run out of the nonprofit institutions Boston Children’s Hospital Computational Health Informatics Program and the Harvard Medical School Department of Biomedical Informatics.^[19] With their $15 million grant,^[20] SMART Health IT developed an open, standards-based technology platform that enables innovators to create apps that seamlessly and securely run across the healthcare system.

Despite the legislation and investment, the hoped-for benefits of improved care and reduced cost proved elusive. In late 2013, the Agency for Healthcare Research and Quality commissioned a study by JASON, an independent panel of experts, to figure out why. The results, published in a paper titled A Robust Health Data Infrastructure, found that:^[21]

• The current lack of interoperability among data resources for EHRs is a significant impediment to the exchange of health information and the development of a robust health data infrastructure. Interoperability issues can be resolved only by establishing a comprehensive, transparent, and overarching software architecture for health information.

• The goals of improved healthcare and lowered healthcare costs can begin to be realized if health-related data can be explored and exploited in the public interest, for both clinical practice and biomedical research. That will require implementing technical solutions that both protect patient privacy and enable data integration across patients.

HHS created a JASON Task Force in 2014 to respond to the findings of the report.^[22] The JASON Task Force criticized the JASON study, claiming it did not capture all the progress made. Still, in the end, the Task Force agreed with JASON’s primary finding on the lack of interoperability as the critical problem.

Making the turn toward interoperability

The JASON report represented a crucial turning point in US healthcare policy. Before JASON, the focus was on promoting the adoption of healthcare technology. After JASON, the focus shifted to supporting the interoperability of the technology. This change is visible in legislative and executive action.

Passed in 2016, the 21^st Century Cures Act (Cures Act)^[23] was primarily targeted at streamlining the drug and medical device approval processes. Also, Title IV of the Cures Act defined the term “interoperability” for health IT^[24] and established penalties for deterring interoperability by information blocking, imposing fines of up to $1 million per violation.^[25] The intention is to promote the use of electronic health records to improve care, empower patients, and improve access to their electronic health information.

President Trump signed Executive Order 13813 “Promoting Healthcare Choice and Competition Across the United States” on October 12, 2017.^[26] The Executive Order is intended to “re-inject competition into healthcare markets” and improve Americans’ access to quality of information, thereby allowing them to make better-informed healthcare decisions.

CMS Administrator Seema Verma announced the MyHealthEData initiative on March 6, 2018.^[27] This initiative “aims to empower patients by ensuring that they control their healthcare data and can decide how their data is going to be used, all while keeping that information safe and secure.”^[28] Ultimately, the initiative aims to facilitate every American’s ability to find the providers and services that best meet their unique healthcare needs and give that provider secure access to their health information.

As further evidence of the change in policy direction, CMS renamed its EHR Incentive Program, formerly known as Meaningful Use, to the Promoting Interoperability Program.^[29] This change, made in April 2018, was not merely a name change but also represented an increased focus on interoperability and improving patient access to health information through the measurement of the adoption of certified health IT.

Accelerating forward with implementation

The new final rules implement portions of the Cures Act, contribute to fulfilling Executive Order 13813, and support President Trump’s MyHealthEData initiative. How the rules accomplish this is summarized below.

The ONC final rule, titled the “21^st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program,”^[30] implements the interoperability provisions of the Cures Act to facilitate the flow of information between providers, payers, and patients. It hopes to achieve this by making changes to ONC’s health information certification program, regulating information blocking, and implementing standards for application programming interfaces (APIs) to exchange healthcare information. The new certification requirements apply to certified health IT developers. The API requirements apply to these same vendors but also healthcare providers and healthcare information networks.

The CMS final rule, titled the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers,”^[31] requires payer-to-payer data exchange, use of the ONC API standards when implementing patient access APIs and provider directory APIs, and adopting conditions of participation notice requirements. The CMS final rule applies to Medicare Advantage organizations, Medicaid managed care plans, state Medicaid agencies, state Children’s Health Insurance Program (CHIP) Agencies, Managed Care entities, and federally facilitated exchanges.

Potential bumps in the road

When first proposed, the rules were met with controversy, particularly over the implications for the security and privacy of protected health information. The debate or concerns fell into four areas:

1. HIPAA will generally not cover the third-party app providers, and user’s private health information will be sold and exploited.

2. Transfers may include information that an enrollee or beneficiary does not want exchanged, such as mental health, substance abuse, women’s health, and family history.

3. APIs are generally risky, and the required Fast Healthcare Interoperability Resources standard is new; therefore, it does not make sense to allow unregulated third-party apps access through an API at this time.

4. Provider HIPAA liability for the information provided through an API or for denial or discontinuance of access through the API.

HHS addressed each of these concerns in its Response to Public Comments published in the Federal Register as part of the final rules.^[32]

Commenters assume that many, if not most, third-party app vendors will be providing their applications directly to the public, and the HIPAA Security, Privacy, and Breach Notification rules will not apply. Instead of the protections of HIPAA, third-party app developers’ use of the information would be covered under the app’s terms of use and privacy policy. The concern expressed by commenters is that many app users will not read or understand the user agreement and privacy policy, so they will not knowingly consent to the use or sale of their information by the third-party app provider. The third-party app providers will, in turn, monetize the data, distribute it widely, not protect it, and exploit it to the detriment of the individual to whom the information relates. Together, these two factors will effectively defeat the purposes of HIPAA.

HHS’s response to this argument is that individuals are entitled to their health information. The public is now much more familiar with technology and, in particular, applications provided for use on devices such as smartphones. The Federal Trade Commission enforces violations of privacy policies, and there are state privacy laws and regulations as well. Furthermore, healthcare organizations are welcomed and encouraged to offer education and awareness training to the public on the use of third-party applications and the risks to the security and privacy of their health information. However, organizations may not actively prevent an individual’s use of a third-party application except as provided in the regulations.

There were several public comments related to concerns commenters have around the transfer of particularly sensitive information. Examples include information such as mental health, women’s health, substance abuse, or family history. Commenters worried that providers may discriminate based on this information. Commenters also expressed concern that family members’ information will be shared through the APIs without the individuals’ consent as part of family history.

In response to these concerns, HHS stated that payers’ privacy and security obligations under the HIPAA rules and 42 C.F.R. § 2 are not changed by this final rule. HHS is continuing to work on standards for parsing and segmenting data for consent and privacy management purposes. The health information the rules require to be shared at this time includes claims and encounter data, as well as the data contained in the United States Core Data for Interoperability, Version 1.^[33] Family history is not a specific data class within the United States Core Data for Interoperability. As a result, HHS does not believe this should be an issue.

There were several concerns raised around the security of the APIs. An API is a software intermediary that allows two applications to talk to each other. One might think of an API as a contract between two applications that facilitates requests for information and responses. API implementations can be quite complex, and errors in their implementation and vulnerabilities in protocols used can result in unauthorized disclosures of information in the connected application.

HHS responded to these concerns by stating that it believes that the security protocols at 45 C.F.R. § 170.215 are sufficient to authenticate users and authorize individuals to access their data. Also, the HIPAA Security Rule requirements still apply until an organization uploads the information into the third-party app or other recipient’s system. The safeguards under the rule, such as risk analysis, technical evaluations, audit, and encryption, apply to the required APIs.

There were several concerns related to the potential of HIPAA liability for issues with the API. The fears expressed were mostly associated with the use of the data after it is accessed. In its response, HHS was relatively clear on where the boundary line of HIPAA liability resides, and it is at the point where the data enters the third-party application. The security and privacy of electronic protected health information within the organization’s environment, passing through the API or over the internet to the third-party app, is still the responsibility of the organization for HIPAA compliance purposes. Furthermore, if an organization determines through HIPAA risk analysis that the exchange of information with a particular app or third-party developer is too risky, it may deny access.

The road ahead

Table 1 lists the original compliance dates for requirements under the new rules. Some of these dates have changed due to COVID-19. Organizations should check with HHS for the most current deadlines.

The cost associated with implementing the new rules is not trivial. HHS estimates it will cost organizations billions of dollars to implement and maintain the required APIs and data exchanges. The risks associated with implementing the APIs are high. It is quite likely that developers and IT administrators will make mistakes. It is also inevitable that hackers will go after these APIs. Together, these threats will cost organizations millions more as a result of data breaches.

Are these projected costs so high as to justify not going forward with the new requirements? Those calling the shots in the federal government, and particularly at HHS, do not think so. They are probably right if the new rules deliver us to the hoped-for destination of improved care at a reduced cost. If, however, these new rules don’t achieve that goal, then the industry will be left to wonder where to turn next or whether we are searching for a destination that might not exist.

Takeaways

• This May, the U.S. Department of Health & Human Services published two final rules targeted at improving interoperability and patient access to health information.

• When first proposed, the rules met with controversy, particularly over the implications for the security and privacy of protected health information.

• The security and privacy of electronic protected health information within an organization’s environment or passing over the internet to a third-party app is still the responsibility of the organization for HIPAA compliance purposes.

• The risks associated with implementing necessary application programming interfaces are high and should be carefully considered.

• If an organization determines through HIPAA risk analysis that the exchange of information with a particular app is too risky, it may deny access.