ONC, CMS Finalize Transforming Interoperability and Patient Access to Data Rules

The Centers for Medicare & Medicaid Services (CMS) and the Office of the National Coordinator for Health Information Technology (ONC) on March 9, 2020, released separate but related final rules addressing interoperability, information blocking, patient access to data and electronic health record (EHR) certification criteria. Notably, not much changed from the proposed regulations. Both agencies are moving forward despite some industry pushback.

The Final Rules draw on the policies advanced in the 21st Century Cures Act (Cures Act), directing ONC and CMS to develop policies that foster the interoperable exchange of health information between stakeholders. Among other provisions, the Cures Act urged the implementation of application programming interfaces (APIs) to modernize data exchange and better facilitate patient access to their health information.

The ONC rule finalizes significant changes to the health information technology (IT) certification program that will require developers to update to their technology. The Final Rule also clarifies how the healthcare industry can prevent information blocking among healthcare providers, health IT developers, exchanges and health information networks. However, stakeholders have expressed concern that the Final Rule does not address protecting private patient data from third parties.

The CMS rule finalizes the agency's plan to improve access to the clinical, encounter, claims and other types of data that can be shared among patients, plans and federal agencies through Fast Healthcare Interoperability Resources (FHIR)-standard APIs. The Final Rule also finalizes ways that CMS can discourage information blocking, capture more electronic addresses for providers and require hospitals to send admission, discharge electronically and transfer notifications.

• ONC Final Rule
• CMS Final Rule
• Fact Sheet about the Final Rules

Below is a summary of the significant provisions from each Final Rule:

ONC 21st Century Cures Act: Interoperability, Information Blocking and the ONC Health IT Final Rule

The policies in the ONC Rule directly impact healthcare providers, developers of Certified Health IT, health information networks and exchanges. They will also affect any entity that creates, accesses or exchanges electronic health information as part of its business model.

Types of Actors

ONC's Final Rule streamlines and updates definitions of the kinds of "Actors" to which the information blocking provisions apply.

• Healthcare Providers: The final definition still references the definition of "healthcare provider" in Section 3000 of the Public Health Service Act (as opposed to the definition of the healthcare provider in the Health Insurance Portability and Accountability Act  or HIPAA). ONC notes that this choice allows the U.S. Department of Health and Human Services (HHS) Secretary some latitude in expanding the definition over time.
• Developers of Certified Health IT: ONC finalized its definition to include an individual or entity that develops or offers Certified Health IT – meaning that developers of other, noncertified health technology are not targets of information blocking enforcement. In general, Certified Health IT is health technology, primarily electronic health record (EHR) systems, which meet certain standards adopted by ONC. However, developers of Certified Health IT can be found in violation of information blocking concerning noncertified products as well. 
• Health Information Networks and Exchanges (HIN and HIE): ONC opted to combine these two terms into a single definition and narrowed their scope. An entity is a HIN/HIE if it determines, controls or has the discretion to administer any requirement, policy or agreement that permits, enables or requires the use of any technology or services for access, exchange or use of electronic health information (EHI) among more than two unaffiliated individuals or entities, but only for a limited set of purposes drawn from HIPAA: treatment, payment and healthcare operations. This excludes entities that only serve patients by providing individual access to EHI. ONC also clarified that HINs and HIEs must control the flow of EHI among multiple other entities, meaning that bilateral exchange between only two entities would not fall under this definition. An entity is a HIN or HIE based on the functions they engage in, regardless of how they are defined in the market.

Information Blocking

The ONC rule implements the information blocking provisions of the 21st Century Cures Act. The Cures Act created a new legal prohibition against information blocking – defined as any practice that is likely to interfere with, prevent or materially discourage access, exchange or use of electronic health information.

Compliance with the information blocking prohibition is required for a limited set of data starting six months from the date of publication of the Final Rule (estimated September 2020), and beginning 24 months after the date of publication with respect to all EHI (estimated March 2022).

However, enforcement of information blocking civil monetary penalties (CMP) will not begin until established by future notice and comment rulemaking by the Office of the Inspector General (OIG). As a result, Actors would not be subject to penalties until CMP rules are final.

Providers, health IT developers, health information exchanges and health information networks are all considered "Actors" in the prevention of information blocking. ONC finalized eight exceptions (up from seven in the Proposed Rule) to the definition of information blocking. An Actor will not be subject to enforcement actions under the information blocking provision for CMP or appropriate disincentives if the Actor's practice satisfies at least one exception. However, failure to meet the conditions of an exception does not automatically mean a practice constitutes information blocking. A practice failing to meet all conditions of an exception only means that the practice would not have guaranteed protection from CMPs or appropriate disincentives. The practice would instead be evaluated on a case-by-case basis to assess the specific facts and circumstances.

The eight exceptions are as follows:

• Content and Manner Exception (New). To meet this new exception, an Actor's practice of limiting the content of its response or the manner in which it fulfills a request to access, exchange or use EHI will not be considered information blocking if the practice meets both a "content condition" and "manner condition." Under the content condition, an Actor may respond to a request to access, exchange or use EHI with a set of EHI limited to the data elements in the U.S. Core Data for Interoperability (USCDI) standard for 18 months following the Final Rule's compliance date (i.e., between months 6 and 24 after publication). Under the manner condition, an Actor must respond in the manner requested unless technically unable to respond or agreeable license terms cannot be reached, in which case it must respond in an alternative manner based on the order of priority specified in the Final Rule, as well as provide the means for the requestor to interpret the EHI, as agreed upon with the requestor.
• Preventing Harm Exception. To meet this exception, the ONC defined conditions must be met: a) the Actor has a reasonable belief that the practice will substantially reduce risk of harm to a patient another person, b) the practice is no broader than necessary, and c) the type of risk and harm meets ONC's criteria.
• Privacy Exception. To meet this exception, all of the requirements of at least one of the four defined sub-exceptions must be met. The sub-exceptions are: a) one or more federal or state preconditions for the access, exchange or use of EHI have not been satisfied, b) the Actor is a Certified Health IT developer that is not subject to HIPAA, c) the patient has elected to restrict the sharing of their EHI, and d) respecting an individual's request not to provide access, exchange or use of EHI. Each of these sub-exceptions requires having and disclosing organizational policies to support these criteria to the individuals and entities that use the Actor's product or service before they agree to use them. This exception is limited.
• Security Exception. To meet this exception, their practices are: a) directly related to safeguarding the confidentiality, integrity and availability of EHI, b) the practice is tailored to specific security risks, and c) the practice is implemented in a consistent and nondiscriminatory manner. In addition, the practice must be part of an organizational security policy or be based on particularized facts and circumstances that demonstrate that the practice is necessary to mitigate security risk and that there are no reasonable and appropriate alternatives to the practice.
• Infeasibility Exception. To meet this exception, the practice must be infeasible a) due to uncontrollable events such as public health emergencies, war, etc., b) the Actor does not have the ability to segment the requested EHI from EHI that cannot be disclosed due to the individual's preference or legal restrictions, or c) the Actor has determined that the request was infeasible after evaluating the factors described in the Rule in a consistent and nondiscriminatory manner.
• Health IT Performance Exception. To meet this exception, the Actor's practices must be related to the maintenance and improvement of health IT (e.g., temporary unavailability of data or degradation of the performance of health IT). These practices must last no longer than necessary.
• Fees Exception. To meet this exception, fees must meet a number of conditions (e.g., be based on objective and verifiable criteria applied uniformly to similarly situated classes of persons or entities and requests) and must not be based on certain prohibited factors (e.g., whether the requestor is a competitor). If an Actor is a health IT developer, the Actor must also comply with all relevant conditions of certification. The exception excludes certain fees, such as specific fees based on electronic access to EHI by the individual.
• Licensing Exception. To meet this exception, an Actor practice to license interoperability elements for EHI to be accessed, exchanged or used will not be considered information blocking if the practice meets certain timing requirements and licensing conditions. The Actor must begin license negotiations with the requestor within 10 business days from receipt of the request and negotiate a license within 30 business days from receipt of the request. Royalties and terms of the license also generally must be reasonable and nondiscriminatory per specified licensing conditions.

Definition of Electronic Health Information (EHI)

ONC updated the definition of EHI that was previously defined broadly. The Final Rule narrows the definition to mean electronically protected health information (ePHI) as defined in HIPAA, to the extent that ePHI would be included in a designated record set. This requirement is regardless of whether the records are used or maintained by or for a covered entity as defined under HIPAA. De-identified data is excluded from the definition of EHI. Also, EHI will not include psychotherapy or information compiled in reasonable anticipation of, or for use in, civil, criminal or administrative actions or proceedings.

As noted above, compliance with the information blocking rule for all EHI as defined under the Final Rule is not required until 24 months from publication of the Final Rule. From six months after publication through the 24-month deadline, the scope of EHI subject to the information blocking prohibition will be limited to only data types described in the USCDI. In other words, a grace period between all the data and the data provided in USCDI.

Health IT Certification Program

The Final Rule updates the 2015 Edition Health IT Certification criteria. Certification criteria have been removed, revised or newly added to support evolving health IT standards and interoperability. Among various changes, the Final Rule adds the two technical certification criteria (Electronic Health Information Export and Standardized API for Patient and Population Services) and two privacy and security criteria (Encrypt Authentication Credentials and Multifactor Authentication).

ONC also advanced the removal of the Common Clinical Data Set (CCDS) definition and its references from the 2015 Edition and is replacing it with the adoption of the USCDI standard (this provision was included in the draft Trusted Exchange Framework and Common Agreement). The USCDI is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange. The USCDI includes more data than CCDS. For example, clinical notes.

IT developers must update their software to comply within 24 months for revised and 36 months for newly added criteria.

CMS Interoperability and Patient Access Final Rule

Privacy, Security and Standards

CMS, in partnership with the ONC, identified Health Level 7® (HL7) FHIR Release 4.0.1 as the foundational standard to support data exchange via secure application programming interfaces (APIs).

In response to widespread privacy concerns with non-HIPAA-covered direct-to-consumer applications, CMS repeatedly noted that it does not have the authority to regulate third-party applications and referred to the Federal Trade Commission's (FTC) authority over these entities.

Also, regarding privacy, CMS placed new emphasis on requiring health plans to educate their enrollees about the risks associated with sending personal health data to third-party apps that are not regulated by HIPAA privacy protections. Plans must post privacy and security resources to a public website, including a discussion about a third-party app's secondary use of data.

Patient Access to Application Programming Interfaces (APIs)

CMS-regulated payers, specifically Medicare Advantage organizations, Medicaid Fee-for-Service (FFS) programs, Medicaid managed care plans, Children's Health Insurance Program (CHIP) FFS programs, CHIP managed care entities and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs), excluding issuers offering only stand-alone dental plans (SADPs) and QHP issuers offering coverage in the Federally-facilitated Small Business Health Options Program (FF-SHOP), are required to implement and maintain a secure, standards-based (HL7 FHIR Release 4.0.1).

These payers are required to implement a standards-based (HL7 FHIR) Patient Access Open API beginning Jan. 1, 2021 (for QHP issuers on the FFEs, plan years beginning on or after Jan. 1, 2021) that allows third-party apps to retrieve, with the approval of a current enrollee, any adjudicated claims (including provider remittances and enrollee cost-sharing), encounters with capitated providers, clinical data (including lab results) that plans have maintained with a date of service on or after Jan. 1, 2016.

In the Final Rule, CMS confirmed that states and managed care plans must make adjudicated claims and encounter data available through the API for all Medicaid- or CHIP-covered services, including long-term services and supports (LTSS), i.e., social determinant data related to long-term care waiver services, such as in-home care, meal preparation or delivery, and transportation.

Data must be made available no later than one business day after a claim is adjudicated or encounter data are received. Regarding claims data, CMS acknowledged that giving people access to past cost information (from claims data) does not mean that they can negotiate or impact future healthcare costs, but it may "help them plan for future services."

In response to widespread privacy concerns with non-HIPAA-covered direct-to-consumer applications, CMS repeatedly noted that it does not have the authority to regulate third-party applications and referred to FTC's authority over these entities. CMS also placed new emphasis on requiring health plans to educate their enrollees about the risks associated with sending personal health data to third-party apps that are not regulated by HIPAA privacy protections.

Also of note, CMS proposed requiring that payers in CMS programs be able to participate in a trusted exchange network, which verifies the security and identity of participants and lets providers and plans share information regardless of what health IT network they belong. One thing to note is that plans do not have to join a trusted exchange network right away. CMS agreed with commenters that work on the Trusted Exchange Framework, and Common Agreement (TEFCA) needs to progress further before finalizing this part of the rule.

Payer-to-Payer Data Exchange

As of Jan. 1, 2022, CMS payers must comply with patients' requests to send their clinical data, inclusive of the elements defined in the U.S. Core Data for Interoperability (USCDI) version 1 data set, to other CMS payers, to ensure that the new payer has patients' complete records if they change plans. USCDI version 1 includes high-level clinical data including allergies, clinical notes, patient goals and health concerns, immunizations, laboratory tests and results, medications, procedures and vital signs. As expected, the USCDI standard aligns with the ONC Rule's definition and exceptions for information blocking and the same API standard for exchanging patients' electronic health information.

Dual Eligible Coordination

Starting on April 1, 2022, state agencies will be required to exchange Medicare and Medicaid dual enrollee data daily with CMS. Currently, states are only required to exchange this data monthly.

Condition of Participation (CoP)/Admission, Discharge and Transfer (ADT) Notifications

Regarding providers, CMS finalized the conditions of participation (CoP) to require facilities to send key event notifications to other providers caring for a patient known as admit-discharge-transfer (ADT) notices. In contrast to the Proposed Rule, this requirement includes event notification requirements for any patient who accesses services in hospital emergency departments or any inpatient hospital services.

The new CoP for all Medicare and Medicaid participating hospitals requires that hospitals using an electronic medical records system or other electronic administrative system demonstrate:

1. The system is operational and used for the exchange of patient health information.

2. The system sends notifications that must include at least a patient name, treating practitioner name and sending institution name.

3. Consistent with federal and state law and regulations, and not inconsistent with the patient's expressed privacy preferences, the system sends notifications at the time of:

• registration at the emergency department
• admission to the hospital's inpatient services
• the patient's discharge or transfer from the hospital's emergency department
• the patient's discharge or transfer from the hospital's inpatient services

4. The system sends the notifications to all applicable post-acute care services providers and suppliers, the patient's primary care physician or any other provider that the patient indicates is primarily responsible for his or her care.

The Final Rule does not include the proposed requirement that the notifications include diagnosis information, although hospitals may decide to include diagnosis or additional information beyond the minimum required.

The change to the CoPs will be effective six months (estimated September 2020), after the Final Rule is published in the Federal Register. This is a short time frame for hospitals to send electronic notifications about admission, discharges or transfers because CMS believes that the content exchange standard is common to many EHR systems.

Public Reporting and Information Blocking

By late 2020, eligible clinicians, hospitals and critical access hospitals (CAHs) must attest that they support electronic access to health information, and list or update their digital contact information to the National Plan and Provider Enumeration System (NPPES) or CMS will publicly report them (e.g., Physician Compare).

Provider Directory

By Jan. 1, 2021, plans must make standardized information about their provider networks available through a published Provider Directory API.

Advancing Interoperability in Innovative Models

CMS sought public comment on promoting interoperability among model participants and other healthcare providers as part of the design and testing of innovative payment and service delivery models. No additional information has been released from the Center for Medicare and Medicaid Innovation (CMMI) about these plans, and CMS did not propose any new regulations for comment in the Final Rule.

Important Dates

• Patient Access API (Jan. 1, 2021)
• Provider Directory API (Jan. 1, 2021)
• Payer-to-Payer Data Exchange (Jan. 1, 2022)
• Improving the Dually Eligible Experience by Increasing the Frequency of Federal-State Data Exchanges (April 1, 2022)
• Public Reporting and Information Blocking (Late 2020)
• Digital Contact Information (Late 2020)
• ADT Event Notifications (Fall 2020) 

Information contained in this alert is for the general education and knowledge of our readers. It is not designed to be, and should not be used as, the sole source of information when analyzing and resolving a legal problem. Moreover, the laws of each jurisdiction are different and are constantly changing. If you have specific questions regarding a particular fact situation, we urge you to consult competent legal counsel.