What the ONC and CMS Final Rules For Interoperability Mean for Data Exchange and Patient Access to Health Information

While the healthcare industry is under siege battling COVID-19, on March 9, 2020, the U.S. Department of Health and Human Services (HHS) moved ahead and finalized two long-awaited and controversial rules related to information blocking, use of application programming interfaces (APIs), and other health IT issues.

These rules will significantly impact healthcare providers, health plans, health IT vendors, and patients in the years ahead. Some of the key rules are as follows:

• Healthcare providers and health IT companies should assess their practices involving electronic health information (EHI) to ensure that they are not intentionally or inadvertently engaging in “information blocking”;
• Hospitals will have new Conditions of Participation requiring them to make reasonable efforts to send real-time electronic patient event notifications to certain other healthcare providers and their business associates (such as other providers’ accountable care organizations);
• Healthcare providers and health plans should prepare for greater automated access to their patients’ and plan members’ health information and should consider educating their patients and members about the benefits and potential risks involved in using third party apps to access and aggregate their information; and
• Health IT companies should adapt to the API standards, prepare for third party applications accessing EHI in their systems, and consider how they will comply with federal and state privacy and security requirements other than HIPAA, such as the FTC Act, the California Confidentiality of Medical Information Act, the Texas Medical Records Privacy Act, and others.

For some, these regulations mark a watershed moment in consumers’ access to their health information, potentially enabling unprecedented health IT innovation. For others, these rules present both an immediate danger to patient privacy by funneling health data outside of the protections of HIPAA and into a perceived privacy “Wild West,” and a potentially murky intrusion into current commercial contracting practices related to health information sharing.

Background

In 2016, Congress passed the bi-partisan 21st Century Cures Act (Cures Act) to drive the electronic access, exchange, and use of health information. The Cures Act evinces lofty information-sharing goals by breaking down barriers in the nation’s health system to improve interoperability, unleash innovation, and allow patients better access to their health information, while reducing burdens on payers and providers. The premise is that when data flows freely and securely between payers, providers, and patients, the healthcare system can achieve coordinated care, improved health outcomes, and reduced costs.

On March 9, 2020 the Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare & Medicaid Services (CMS) published separate, but related, final rules addressing interoperability, information blocking, standards to support data exchange via secure APIs, and patient access to data and electronic health records. The final rules build upon proposed rules that were published by CMS and ONC in February 2019.

The ONC Rule focuses on significant changes in its existing health information technology certification program. Specifically, the ONC Rule implements the interoperability provisions of the Cures Act to allow for seamless data exchange among healthcare providers, payers, and patients. The ONC Rule holds health IT developers accountable as a condition of certification. However, the ONC’s key regulatory provisions – information blocking and information exchange via APIs – will also apply to healthcare providers and healthcare information networks.

The CMS Rule addresses many of the same patient access and interoperability issues as the ONC Rule, but it applies to Medicare Advantage (MA), Medicaid, CHIP, and Qualified Health Plan (QHP) issuers on Federally-facilitated Exchanges (FFEs). CMS is using its regulatory authority over these healthcare providers and entities to further interoperability and patient access to digital health information. The CMS Rule encourages interoperability, innovation and patient empowerment by requiring payer-to-payer data exchange, implementing the ONC’s API standards, adopting conditions of participation (CoP) notice requirements, and publicly reporting providers that may be information blocking .

These new Rules have been marked by controversy, with certain key industry stakeholders heavily lobbying HHS to delay their finalization. Some claim that healthcare providers, health plans, and electronic health record (EHR) vendors should not be forced to disclose sensitive patient information to third party apps whose developers may sell the data. Others claim that these Rules are long overdue, and that consumers have the right to access their information through the app of their choice.

Information Blocking

What Is Information Blocking?

Section 4004 of the Cures Act defines information blocking as a practice by a healthcare provider, health IT developer, health information exchange, or health information network that, except as required by law or specified by the HHS Secretary as a reasonable and necessary activity, is likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI.

Both the Cures Act and ONC specify certain practices that may constitute information blocking:

• Imposing formal or informal restrictions on access, exchange, or use of EHI;
• Implementing health information technology in ways that are likely to restrict the access, exchange, or use of EHI with respect to exporting complete information sets or in transitioning between health information technology systems;
• Discouraging efforts to develop or use interoperable technologies or services by exercising influence over customers, users, or other persons;
• Discrimination that frustrates or discourages efforts to enable interoperability; and
• Rent-seeking and opportunistic pricing practices that make information sharing cost-prohibitive.

Definition of EHI

The ONC Rule uses HIPAA’s definition of electronic protected health information (ePHI) to define EHI, to the extent that ePHI would be included in a designated record set regardless of whether the records were used or maintained by or for a covered entity as defined under HIPAA. EHI excludes psychotherapy notes, de-identified information, or information compiled in reasonable anticipation of, or for use in, civil, criminal, or administrative actions.

Of note, EHI does not include ePHI that falls outside of a designated record set, such as ePHI that is used for internal quality improvement, business analytics, or otherwise is not used to make decisions about the individual who is the subject of the ePHI. The ONC Rule does not require the sharing of such ePHI.

To Whom Do the Information Blocking Regulations Apply?

Three categories of “actors” are regulated by the information blocking provisions in the ONC Rule:

1. Healthcare providers (e.g., healthcare facilities, laboratories, pharmacies, physicians, etc.);


2. Health information networks; and


3. Health IT developers of certified health IT.

When Must Actors Comply?

The information blocking section’s compliance date is six months after the ONC Rule is published in the Federal Register (Fall 2020). For the first 18 months after the compliance date, actors must only comply with the information blocking requirements with respect to the limited EHI identified by the data elements represented in the U.S. Core Data for Interoperability (USCDI). Thereafter, Actors will need to expand compliance to include the full scope of EHI captured by the definition in the Cures Act.

Are There Any Exceptions? (Yes!)

Section 4004 of the Cures Act authorizes HHS to identify reasonable and necessary activities that do not constitute information blocking. The ONC Rule identifies eight categories of exempt activities, provided all specified conditions are met. These exceptions to the information blocking definition are intended to support seamless and secure access, exchange, and use of EHI, and to give actors some certainty as to when business practices involving accessing, exchanging, or using EHI will not trigger information blocking concerns.

The eight exceptions to the information blocking definition are divided into two categories:

To qualify for any of these exceptions, an actor would, for each relevant practice and at all relevant times, have to satisfy all of the applicable conditions of the exception.

If at least one exception is satisfied, the action would not be treated as information blocking and the actor would not be subject to any civil monetary penalties (CMPs) and/or other disincentives contemplated by the ONC Rule. If an action does not meet all of the conditions of an exception, it does not automatically constitute information blocking. Instead, regulators will evaluate actions on a case-by-case basis to determine whether information blocking has occurred (e.g., whether the practice rises to the level of an interference and whether the actor acted with the requisite intent).

Accordingly, regulated actors are encouraged to align their current business practices with respect to accessing, exchanging, or using EHI, as close as reasonably possible to the above exceptions.

Potential Penalties and Disincentives for Information Blocking

Section 4004 of the Cures Act identifies potential penalties and disincentives for information blocking:

• Health IT developers and health information networks that the Inspector General, following an investigation, determines to have committed information blocking shall be subject to a CMP not to exceed $1,000,000 per violation, for all such violations identified through such investigation. Such determination shall take into account factors such as the nature and extent of the information blocking and harm resulting from such information blocking (e.g., number of patients and/or providers affected, the number of days the information blocking persisted).
• Healthcare providers determined by the Inspector General to have committed information blocking will be referred to the appropriate agency and subjected to appropriate disincentives using authorities under applicable Federal law, as the Secretary of Health and Human Services sets forth through notice and comment rulemaking.

How to File an Information Blocking Complaint

Information blocking complaints can be submitted through the online Health IT Complaint Form, available here.

As specified by the Cures Act, information blocking claims and information received by ONC in connection with a claim or suggestion of information blocking are generally protected from disclosure under the Freedom of Information Act.

Depending on the nature of a claim, ONC may contact the complainant for additional information or, to the extent necessary and permitted by law, share the complaint information provided with other appropriate government agencies, such as the HHS Office of Inspector General.

Information Blocking: Next Steps

Regulated actors should review their information practices involving EHI to ensure that they are compliant with the information blocking requirements. This may include assessing:

• How common requests for EHI from healthcare providers and others are handled;
• How current data-use agreements and similar information sharing arrangements operate;
• Whether fees charged in relation to access, exchange, or use of EHI are permissible; and
• How to implement practices into future commercial transactions to minimize risks of perceived information blocking.

Yes to More Data Exchanges With APIs

Electronic Access, Exchange, and Use of EHI

The ONC and CMS Rules work together to enable the mandate of the Cures Act to drive the electronic access, exchange, and use of EHI by and between patients, healthcare providers, and health plans. One of the ways both rules carry out this mandate is by requiring and standardizing the establishment and use of APIs.

By doing this, both ONC and CMS hope to provide patients more control and access to their own health data “without special effort.” Further, the CMS and ONC Rules will better enable access and exchange of information through use of common technologies, such as smart phones, computers, and tablets, and different applications, such as personal health records.

What Is an API?

An application programming interface, or API, is a “messenger” that works behind the scenes to help software programs or servers communicate with each other. Most individuals have likely used APIs in their everyday lives, without even knowing that they were using them. One example is that your search for an airline flight uses APIs.

Before APIs, individuals would have to visit various airlines’ websites to compare prices. Now, third party applications and websites can aggregate flight information on one page by connecting to the different airlines’ information systems using APIs.

Key definitions:

• Certified API Developer: Health IT Developer that creates certified API technology.
• API Information Source: Healthcare organization that deploys certified API Technology.
• API Users: Persons or entities that create or use software applications that interact with certified API technology.

ONC's New Standardized API for Patient and Population Services

The ONC Rule updates the 2015 Edition Health IT Certification criteria to remove, revise, and add technical criteria and standards to further support interoperability. In particular, the ONC Rule establishes new criteria for Standardized API for Patient and Population Services, which would permit the support of API-enabled “read services” for single and multiple patients.

“Read” services include those that allow an authenticated and authorized third party application to view and access EHI through a secure API. ONC hopes that its new API criteria will permit an open and competitive marketplace for certified APIs and, along with the information blocking rules, prohibit Certified API Developers from engaging in discriminatory and anti-competitive behavior.

Technical Standards for API

ONC has established several technical criteria for certified APIs. In particular, ONC has identified Health Level 7® (HL7) FHIR Release 4.0.1 as the foundational standard to support data exchange via API. Some of the other requirements that certified API technology must have include:

• Support for USCDI.
• Capability of establishing a secure and trusted connection with an application requesting patient data in accordance with ONC’s implementation specifications.
• Ability to perform authentication and authorization for API Users and to issue a refresh token valid for a period of at least three months during the API Users’ initial connection to access data for a single patient.
• Ability to revoke an authorized party’s access to a patient’s information at a patient’s direction.
• Publicly accessible hyperlink, without any additional access requirements, containing the complete documentation of technical requirements and configurations for the API that permit another application to successfully interact with the API and process its responses, including the API’s terms and conditions.

Permissible Fees

The ONC Rule sets forth criteria and guidelines for the fees certified API Developers would be permitted to charge and to whom the fees could be charged. Under the ONC Rule, Certified API Developers are prohibited from imposing additional fees related to certified API technology that are not otherwise permitted by the ONC Rule. Certified API Developers can charge:

• Fees to API Information Sources for the development, deployment, and upgrade of certified API technology, and towards recovering API usage costs.
• Value-added services related to certified API technology, as long as such services are not necessary to efficiently and effectively develop and deploy the software that interacts with the certified API technology.

ONC Compliance Timeline

Certified API Developers with API Technology certified to the criteria in 45 C.F.R. § 170.315(g)(7), (8), or (9) must comply with the ONC Rule’s new requirements within six months of the Rule’s publication in the Federal Register (Fall 2020).

Further, Certified API Developers previously certified to the criterion in 45 C.F.R. § 170.315(g)(8) must provide all API Information Sources technology certified to the ONC Rules’ new criterion under 45 C.F.R. § 170.315(g)(10) by no later than 24 months from the ONC Rule’s publication in the Federal Register (Spring 2022).

CMS Adopts API Standards Finalized in the ONC Rule

The CMS Rule also includes certain requirements for APIs. In particular, the CMS Rule requires CMS-regulated payers to implement and maintain two types of APIs, which can be used by third-party programmers to build applications that give patients access to health information.

These payers have until January 1, 2021 to implement the following new standards, which must meet the standards outlined in the ONC Rule:

1. Patient Access APIs - Patient Access APIs allow patients, through third party apps, to access their own electronic health information, including clinical data, and claim and encounter data, which must be available through the Patient Access API no later than one day after a claim is processed or the data is received by the payer. Payers must include any data with a date of service on or after January 1, 2016.


2. Provider Directory APIs - Provider Directory APIs provide directory information so patients can find information on providers and clinicians. The Provider Directory APIs are separate from the Patient Access APIs and will require covered payers to develop a separate, public-facing Provider Directory API. The CMS Rule sets forth certain data points that must be included in the Provider Directory API and requires that the data be updated within 30 business days of changes to the directory information.

CMS is also adopting the content and vocabulary standards finalized by HHS in the ONC Rule.

Privacy Concerns

While some view more automated access to health data as long overdue, others have expressed concerns that the information will no longer be subject to HIPAA and consumers will not be well positioned to understand how app developers may potentially use their information. While HIPAA generally will not apply to app developers who gain access to health data through APIs, other privacy laws will.

The FTC Act regulates unfair and deceptive trade practices, and the FTC has used this authority to regulate how companies maintain the privacy and security of health data. It often looks to whether entities are violating their privacy policies, or whether privacy practices may harm consumers.

To the extent that the healthcare provider is a federally-assisted substance use disorder treatment program, then the information may be subject to 42 C.F.R. Part 2. This regulation will potentially govern app developers who receive health information through APIs regarding substance use disorders.

Additionally, most states have privacy laws that extend beyond HIPAA. California and Texas, for example, have general health information privacy laws that extend beyond healthcare providers and potentially would govern app developers. And almost every state has privacy laws governing sensitive conditions and treatments, such as HIV status and mental health treatment, which may apply to any recipient of such information, including app developers.

APIs: Next Steps

While the development of APIs may seem highly technical in nature, it raises significant issues that healthcare providers, plans, and health IT companies will need to address:

• Healthcare providers, health plans that fall under the CMS Rule, and health IT companies should coordinate on implementation of the API requirements;
• Healthcare providers and health plans should consider whether they need to educate patients and plan members on the benefits and potential risks of accessing information on consumer apps, including the importance of reviewing privacy policies, and may consider collating a list of recommended apps;
• App developers should prepare to take advantage of increased access to health data, enabling an improved user experience and new functionalities, but should carefully review and ensure that their privacy policies are clear and up to date, and that they understand potential obligations under state privacy laws such as the California Confidentiality of Medical Information Act (which requires consent for most non-treatment uses and disclosures of medical information) and the Texas Medical Records Privacy Act (which broadly defines “covered entities” and includes notice, education, and authorization requirements).

Additional New Rules for CMS-Regulated Payers and Providers

Implementing Payer-to-Payer Data Exchange

The CMS Rule requires CMS-regulated payers, at a patient’s request, to exchange specified data, including the USCDI version 1 data set. Payers have until January 1, 2022 to implement a process for this data exchange that will allow patients to take their information with them when patients move between health plans to different payers’ systems.

New Hospital CoPs Requirements for Electronic Patient Event Notifications

The CMS Rule modifies CoPs applicable to acute care hospitals, psychiatric hospitals, and Critical Access Hospitals (collectively “hospitals”) that utilize an electronic medical record system or other electronic administrative system that conforms to the content exchange standard HL7 version 2.5.1.

Under the new CoPs, hospitals are required to make reasonable efforts to send real-time electronic patient event notifications (e-notifications) to certain required recipients for treatment, care coordination or quality improvement purposes. The new CoPs will be applicable six months after the CMS Final Rule is published in the Federal Register (Fall 2020).

E-notifications must be transmitted:

• When a patient presents or is discharged from the emergency department;
• At the point of an inpatient and/or observation admission, discharge, or transfer.

E-notifications must be transmitted to the patient’s established primary care provider (PCP), established primary care practice group or entity, other practitioners/practice groups/entities identified by the patient as primarily responsible for the patient’s care and applicable post-acute providers who need to receive notification for treatment, care coordination, or quality improvement purposes.

Hospitals can also satisfy this requirement by sending e-notifications to an accountable care organization (ACO) which is acting on behalf of one of the above healthcare providers (as long as an appropriate BAA is in place between the ACO and the other healthcare provider). Hospitals are expected to take steps to standardize e-notifications to help ensure that notification recipients are able to receive them.

E-notification may be transmitted to other entities, practitioners, or individuals relevant to the patient’s post-discharge care (e.g., ACOs, payers, family members), as long as hospitals comply with applicable laws and regulations regarding the sharing of patient data.

E-notifications must contain, at a minimum, the name of the patient, treating provider and transmitting hospital. CMS encourages hospitals to also include the patient’s chief complaint, medication profile, discharge disposition, and diagnosis when appropriate.

Public Reporting to Encourage Provider Compliance

By late 2020, CMS will publicly report:

• Eligible clinicians and hospitals that may be information blocking based on self-attestations to certain Promoting Interoperability Program requirements; and
• Providers who do not list or update their digital contact information in the National Plan and Provider Enumeration System (NPPES).

Increasing the Frequency of Federal-State Data Exchanges

The CMS Rule requires states to exchange enrollee data for individuals who are dually eligible for Medicare and Medicaid on a daily basis beginning on April 1, 2022. This includes state buy-in and Medicare Prescription Drug, Improvement, and Modernization Act (MMA) files for dually enrolled beneficiaries.

CMS Rule: Next Steps

Some potential next steps under the CMS Rule include:

• Payers that are subject to the Rule should begin strategizing about implementing the increased data exchange over the next two years, including contracting for third party assistance, as needed;
• Hospitals should begin identifying how they will send out e-notifications to other providers and their ACOs, including whether they will need to use a third-party platform to do so;
• Providers should update their information in the NPPES and identify who will be able to knowledgably attest that they are not engaging in information blocking; and
• States should assess steps required to increase their data capture capabilities to move their MMA file transfers to CMS from a monthly basis to a daily basis over the next two years, including contracting for third party assistance if needed.