On October 30, 2023, the US Department of Health and Human Services (HHS) Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare & Medicaid Services (CMS) released a long-awaited proposed rule to implement a 21st Century Cures Act provision establishing penalties (called “appropriate disincentives”) for health care providers determined by the HHS Office of Inspector General (OIG) to have committed information blocking. Health care providers have been subject to the information blocking regulations since April 5, 2021, but there has been no enforcement mechanism under the Cures Act to date.

KEY TAKEAWAYS

• While the HHS proposed rule moves the industry one step closer to enforcement of the information blocking regulations against health care providers, it would apply penalties only to health care providers that participate in certain Medicare programs and not to all health care providers that are covered actors under the information blocking regulations.
• HHS has not proposed any disincentives for health care providers that do not participate in the Medicare Promoting Interoperability or Medicare Shared Savings Program (MSSP), or that serve a limited number of Medicare beneficiaries.
• In a blog post accompanying the proposed rule, ONC was unequivocal about its position that “[i]nformation sharing is expected.” What remains unclear is the mechanics of how HHS will apply its proposed disincentives framework, and a close review of the proposed rule reveals several open questions.
• Comments on the proposed rule are due January 2, 2024.

For more information about ONC’s information blocking regulations, including who is a regulated actor, as well as important information blocking definitions and exceptions, see our Special Report. For a discussion of OIG’s final information blocking enforcement rule concerning the penalties for information blocking by health IT developers of certified health IT (certified health IT developers) and health information networks and health information exchanges (HIN/HIEs), plus OIG’s investigation and enforcement procedures, see our Special Report “A Million Reasons to Share: OIG’s Final Rule on Information Blocking Enforcement.”

SUMMARY OF PROPOSED DISINCENTIVES

The proposed rule would establish the following disincentives for certain Medicare-enrolled health care providers that OIG determines committed information blocking and referred to CMS. As discussed below, the ultimate financial impact of disincentives (if any) would vary in some instances based on Medicare reimbursement rather than on the severity of a health care provider’s alleged information blocking conduct or other factors related to interference with access, exchange or use of electronic health information (EHI). The proposed rule does not include disincentives for health care providers that are not enrolled in Medicare.

Hospitals and Critical Access Hospitals

HHS proposes to use the existing Medicare Promoting Interoperability Program for the meaningful use of certified electronic health record (EHR) technology to impose disincentives on eligible hospitals and critical access hospitals (CAHs). Under the proposed rule, an eligible hospital or CAH would not be a meaningful EHR user in an EHR reporting period if OIG refers, during the calendar year of the reporting period, its determination that the eligible hospital or CAH committed information blocking. As a result, a hospital would be unable to earn the three-quarters of the annual market basket increase, and a CAH would have its payment reduced to 100% of reasonable costs, down from 101%.

HHS estimates that this proposal could result in a median disincentive amount of $394,353 and a 95% range of $30,406 to $2,430,766. Of note, the Promoting Interoperability Program does not apply to many other facilities, laboratories, long-term care hospitals and other care sites.

Physicians and Other Clinicians Reimbursed Under the Medicare Physician Fee Schedule

With some exceptions, clinicians reimbursed under the Physician Fee Schedule (PFS) must either participate in a Medicare Advanced Alternative Payment Model (AAPM) or achieve a threshold Merit-based Incentive Payment System (MIPS) performance score to avoid a downward adjustment to their PFS reimbursement. CMS currently calculates the MIPS performance score based on four performance categories: Quality (30%), Improvement Activities (15%), Promoting Interoperability (25%) and Cost (30%). Measures within the four performance categories are scored and combined to make up a clinician’s MIPS final score. Those who score higher than a performance threshold set by CMS for a reporting year (75 points for 2024) can earn a positive adjustment of up to 9% of reimbursement under the PFS in the payment year. Likewise, those below the performance threshold face penalties of up to -9% of reimbursement under the PFS. CMS applies a payment adjustment to the payment year two years after the calendar year of the clinician’s MIPS reporting period. Not all MIPS participants are required to report the Promoting Interoperability category. For example, there are exceptions for facility-based and hospital-based clinicians (e.g., emergency room physicians and providers in ambulatory surgical centers) as well as some small practices.

Under the proposed rule, a clinician who participates in MIPS and is required to report on the Promoting Interoperability performance category would receive a zero score for the category if OIG refers, during the calendar year of the clinician’s reporting period, a determination that the clinician committed information blocking. Since the Promoting Interoperability performance category is currently 25% of the total MIPS score, 75 would be the highest score that the clinician could earn and would likely result in a penalty based on the current MIPS performance threshold for 2024. Those who do not report the MIPS Promoting Interoperability category would not be subject to any disincentives under this proposal.

HHS estimates that the median individual disincentive amount could be a loss of $686 for a clinician, while an estimated median group of six clinicians could see a loss of $4,116, with a range of $1,372 to $165,326 for group sizes ranging from two to 241 clinicians.

Medicare Shared Savings Program

Clinicians can avoid having to participate in MIPS, or can have their reporting requirements reduced, by participating in the Medicare Shared Savings Program (MSSP). CMS is moving to align certified EHR reporting requirements for all MSSP participants with those of the MIPS Promoting Interoperability performance category beginning in the 2025 performance year.

Because MSSP accountable care organizations (ACOs) are not yet required to report under the Promoting Interoperability program, CMS proposes a different disincentive in connection with the MSSP. Under the proposed disincentives rule, if OIG determines that a health care provider that is an ACO or part of an ACO has committed information blocking, that provider would be barred from participating in the MSSP for at least one year. This may result in a health care provider being removed from an ACO or prevented from joining an ACO. In the instance where a health care provider is an ACO, this would prevent the ACO’s participation in the MSSP.

SCOPE OF HEALTH CARE PROVIDERS IMPACTED BY PROPOSED DISINCENTIVES

The information blocking regulations apply to a broad range of health care providers, including facilities such as nursing facilities, long-term care facilities, dialysis facilities, blood centers, ambulatory surgical centers, laboratories and pharmacies, and individual providers such as therapists and pharmacists. However, because only a subset of health care providers is subject to the requirements that are the basis for disincentives under the proposed rule (e.g., the Promoting Interoperability requirements), many health care providers would be, at least initially, excluded from the disincentives framework, even though they are “covered actors” under the Cures Act and the information blocking regulations. In the proposed rule, HHS included a request for information on additional appropriate disincentives HHS should consider for future rulemaking efforts that would apply to the health care providers excluded from the disincentive framework in this rulemaking.

OIG INVESTIGATIVE AUTHORITIES, “REFERRALS” AND INTERSECTION WITH OIG CMP INFORMATION BLOCKING ENFORCEMENT RULE

The application of disincentives to health care providers covered by HHS’s proposal turns on a determination by OIG that the health care provider committed information blocking, so to understand the potential impact of HHS’s proposed rule, it is important to understand OIG’s role in the information blocking ecosystem.

The Cures Act granted OIG the authority to investigate information blocking claims against each type of covered actor—health care providers, certified health IT developers and HIN/HIEs. The Cures Act also granted OIG the authority to impose civil monetary penalties (CMP) against certified health IT developers and HIN/HIEs that violated the information blocking prohibition. OIG published its final rule implementing its CMP authority in the Federal Register in July 2023. That penalty authority, however, does not extend to the health care provider category of covered actors. Instead, the Cures Act requires OIG to refer health care providers that OIG determines have violated the information blocking prohibition to “the appropriate agency to be subject to appropriate disincentives.”

From a procedural perspective, the proposed rule notes that OIG will coordinate with the “appropriate agency” to which OIG plans to make a “referral” during the pendency of OIG’s investigation and before actually making the referral in an effort to ensure that the agency is aware that OIG might make the referral. When OIG actually does make the referral, OIG will provide information about its determination of information blocking, including how the health care provider’s practice met the “intent element” of the prohibition, among other data related to the alleged misconduct.

In the proposed rule, HHS identified OIG’s anticipated information blocking enforcement priorities for health care providers, which are identical to those OIG identified for certified health IT developers and HIN/HIEs except that OIG omitted actual knowledge from its enforcement priorities list for health care providers. This omission reflects the different knowledge standard in the statutory definition of information blocking for health care providers which must know that their alleged information blocking practice is likely to interfere with access, exchange or use of EHI to implicate the prohibition while health IT developers and HIN/HIEs must know or should know that their alleged information blocking practice is likely to interfere to implicate the prohibition.

In connection with OIG’s final rule, OIG provided guidance describing its planned investigative process for entities subject to information blocking CMPs. Interestingly, OIG stated in its final rule that its discussion of its anticipated enforcement priorities and investigative process was limited to those entities subject to CMPs, and not applicable to health care providers that may be referred for appropriate disincentives. Although the proposed rule discusses OIG’s enforcement priorities for health care providers, it largely omits discussion of the underlying investigative process, including whether OIG’s process will similarly include an opportunity for health care providers to discuss an OIG investigation and explain why their conduct either did not implicate the information blocking prohibition, met an exception or was otherwise lawful. This is notable given the absence in the proposed rule of any appeal mechanism by which health care providers could challenge OIG’s information blocking determination. Although there may be some limited opportunities to appeal a disincentive, HHS specifically makes clear that ACO appeals under the MSSP regulations, at least, do not extend to OIG’s underlying information blocking determination. HHS does not discuss any other appeal avenues in the proposed rule.

One would expect that OIG would need to engage with the health care provider to perform a reasonable investigation. But the OIG final rule’s disclaimer and the proposed rule’s omission of meaningful discussion about such interactions leaves open the question of what, if any, reasonable opportunities health care providers would have to make their case before being subjected to disincentives.

“WALL OF SHAME” FOR INFORMATION BLOCKING

The proposed rule would create a framework for public posts on ONC’s website about actors that OIG determines have committed information blocking. For health care providers subject to disincentives, the website would feature:

• The health care provider’s name;
• The provider’s business address (to ensure accurate provider identification);
• The practice found to have been information blocking; the disincentive(s) applied; and
• Where to find additional information, where publicly available, about the determination of information blocking.

HHS also proposes to post similar information on ONC’s website about HIN/HIEs and certified health IT developers that OIG determines have committed information blocking (regardless of whether they resolved their CMP liability with OIG or were subject to a CMP). The proposal is intended to provide transparency into how information blocking conduct is impacting the nationwide health information technology infrastructure.

This approach to transparency is similar to the HHS Office for Civil Rights’ notorious website that lists breaches of unsecured protected health information affecting 500 or more individuals (which is often referred to as the “wall of shame”). The transparency proposal is also an extension of the ONC’s existing website, Information Blocking Claims: By the Numbers, where it publishes statistics on the information blocking claims received through its “Report Information Blocking Portal” since April 5, 2021 (the information blocking compliance date). As of September 2023, ONC and OIG have received more than 800 claims of possible information blocking (including 685 claims against health care providers).

NEXT STEPS

If you would like to submit comments to the proposed rule before the January 2, 2024, deadline, contact any of the authors of this On the Subject or your regular McDermott lawyer or McDermott+Consulting advisor. Health care providers also should consider reviewing their information blocking policies and practices now so that they are ready for a future final rule.

On November 4, 2020, the US Department of Health and Human Services Office of the National Coordinator for Health Information Technology (ONC) published an interim final rule with comment period in the Federal Register that extends certain compliance dates included in ONC’s May 1, 2020, final rule implementing the 21st Century Cures Act. Among other things, the ONC interim final rule pushed the compliance date for ONC’s information blocking provisions from November 2, 2020, to April 5, 2021. The interim final rule did not make substantive changes to the information blocking provisions or ONC’s Health IT Certification Program.

On November 4, 2020, the US Department of Health and Human Services Office of the National Coordinator for Health Information Technology (ONC) published an interim final rule with comment period (ONC IFR) in the Federal Register that extends certain compliance dates included in ONC’s final rule published in the Federal Register on May 1, 2020, to implement certain provisions of the 21st Century Cures Act. A key extension is the change of the information blocking prohibition applicability date (formerly, the “compliance date”) from November 2, 2020, to April 5, 2021. ONC also extended deadlines for certain health IT certification requirements included in the ONC final rule.

The ONC IFR did not establish penalties for information blocking by health care providers or make other substantive changes to the information blocking provisions of the ONC final rule or ONC’s Health IT Certification Program. (For more information regarding the substantive requirements of the ONC final rule, see our prior Special Report.) Rather, ONC stated that it is simply providing an extension in response to the unique circumstances of the Coronavirus (COVID-19) pandemic.

ONC recognized that the original compliance date did not allow sufficient time for covered actors, including certified health IT developers, health care providers and health information networks and health information exchanges (HIN/HIEs), to assess whether their arrangements and practices that involve the access, exchange or use of electronic health information (EHI) comply with the information blocking prohibition and, if appropriate, amend existing arrangements and implement new procedures to avoid information blocking, particularly when many covered actors are on the front lines combating COVID-19. ONC also concluded that certified health IT developers needed more time to update their software to address new requirements for application programming interfaces (APIs), EHI export and other capabilities.

Although appreciated, the ONC IFR—which spent more than a month under Office of Management and Budget review—came at the 11th hour, with many certified health IT developers and health care providers already well along the path of implementing their information blocking compliance strategies. Balancing against the need for resources to directly and indirectly combat the COVID-19 pandemic, certified health IT developers and health care providers can use the additional few months to test and refine information blocking prohibition compliance procedures. Specifically, health care providers should consider whether the additional time allows them to test or revisit their release of information practices or any plans for the availability of EHI through their patient portals. Similarly, certified health IT developers should evaluate whether the extension to the health IT certification criteria deadlines affect their software development timelines.

Stakeholders may submit comments to the ONC IFR through 5 pm EST on January 4, 2021.

The following sections discuss the new compliance dates applicable to (1) certified health IT developers, HIN/HIEs and health care providers, and (2) only certified health IT developers under the ONC’s Health IT Certification Program.

Changes to Key Compliance Dates Applicable to Certified Health IT Developers, HIN/HIEs and Health Care Providers

April 5, 2021

• Information Blocking Provisions

ONC extended the applicability date for the information blocking prohibition from November 2, 2020, to April 5, 2021. The information blocking provisions prohibit practices that the actor knows are likely to interfere with access, exchange or use of EHI, unless the practices are required by law or are covered by one of the eight exceptions established by ONC. For health care providers, the provider must also know that the practice is unreasonable for it to constitute prohibited information blocking. For the first 18 months, the information blocking provisions will only apply to EHI identified by the data elements represented in the US Core Data for Interoperability (USCDI).

October 6, 2022

• Scope of Information Blocking Provisions Expands to the Full Electronic Designated Record Set

ONC changed the date on which the scope of the information blocking provisions expands from the data elements represented in the USCDI to the full electronic designated record set as defined in the HIPAA regulations from May 2, 2022, to October 6, 2022.

Changes to Key Dates Applicable Only to Certified Health IT Developers

April 5, 2021

The ONC IFR extended the compliance date for the following health IT certification requirements applicable to certified health IT developers from November 2, 2020, to April 5, 2021.

• Information Blocking Condition of Certification (CoC) requirement

The Information Blocking CoC provides that a certified health IT developer must not engage in practices that constitute information blocking. Thus, in addition to potential civil monetary penalties for information blocking under the Cures Act, a certified health IT developer may jeopardize its products’ certification status if it engages in information blocking. The April 5, 2021, compliance date for the CoC aligns it with the new applicability date for the ONC final rule’s separate information blocking provisions.

• Assurances CoC and Maintenance of Certification (MoC) requirements

The ONC final rule’s Assurances CoC requires certified health IT developers to provide satisfactory assurances that they will not take any action that constitutes information blocking, and will ensure that their health IT conforms to the full scope of the certification criteria. The Assurances MoC requires certified health IT developers to retain all records and information necessary to demonstrate initial and ongoing compliance for 10 years beginning from the date the developer’s health IT is first certified.

• API CoC – compliance for current API criteria

The ONC final rule’s API CoC requires health IT developers that offer certified APIs to allow EHI to be accessed, exchanged and used through the certified API without special effort, and to publish complete business and technical documentation via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. The CoC also establishes specific limitations to fees, terms and conditions that certified health IT developers may apply to their certified APIs.

• Communications CoC/MoC requirements

The Communications CoC provides that a certified health IT developer must not prohibit or restrict communications regarding the usability, interoperability or security of its health IT; the developer’s business practices; or the manner in which someone has used the developer’s health IT. Until developers have revised their contracts with customers and other contractors in accordance with the CoC, the Communications MoC requires developers to issue an annual written notice to the customers and contractors stating that they may make communications on these topics, even if the customer has agreed to contract provisions that contradict the CoC and would otherwise prohibit such communications.

December 15, 2021

• Submission of initial plan for real world testing

The ONC final rule requires certified health IT developers to submit testing plans to their certifying bodies to test a subset of certified health IT functionality in the setting(s) where the certified health IT modules are (or will be) marketed.

April 1, 2022

• Submission of initial attestations

Certified health IT developers are required to attest on a semiannual basis beginning on April 1, 2022, that they are in compliance with applicable CoC and MoC requirements.

December 31, 2022

The ONC IFR extends the deadline for certified health IT developers to update their software to include certain new certified capabilities from May 2, 2022, to December 31, 2022:

• New standardized API functionality

Certified health IT developers with certified APIs are required to make available FHIR-based APIs certified to § 170.315(g)(10) by no later than December 31, 2022.

• 2015 Edition health IT certification criteria updates in the ONC final rule (except for the updated EHI export capability, which is extended until December 31, 2023)

Certified health IT developers must update health IT modules certified to various other 2015 edition certification criteria to address revised standards and specifications established under the ONC final rule.

March 15, 2023

• Submission of initial results of real-world testing

The ONC final rule requires certified health IT developers to submit the results of real-world testing of each of their certified health IT modules to their certifying bodies each calendar year. The ONC IFR provides that the first real-world testing results report is not due until March 15, 2023.

December 31, 2023

• EHI export capability must be made available

The ONC final rule requires certified health IT developers of health IT modules that are part of a product that electronically stores EHI to provide customers with the ability to export EHI from the product in accordance with a new EHI export certification criterion. This criterion includes the ability to export the EHI of both a single patient and the entire patient population.

* * *

In conjunction with the release of the ONC IFR, ONC also issued Frequently Asked Questions on its website. Certified health IT developers and other actors regulated under the ONC final rule should review the Frequently Asked Questions and work with counsel to evaluate whether the guidance affects stakeholders’ approaches to information blocking compliance.

Please do not hesitate to contact your regular McDermott lawyer or any of the authors of this On the Subject if you have questions about or need assistance implementing compliance with the ONC final rule or its extended compliance dates.

Under the Office of the National Coordinator for Health IT (ONC) 21st Century Cures Act final rule, effective July 1, 2020, health care providers, in their capacities as such, are not subject to information blocking civil monetary penalties. However, health systems, hospitals and other health care providers may face information blocking civil monetary penalties if they engage in activities that cause them to be a health information technology (IT) developer of certified health IT (Certified Health IT Developer) or health information network or health information exchange (HIN/HIE), and engage in activities that are “likely to interfere” with the access, exchange or use of electronic health information (EHI). This On the Subject discusses whether a health system or provider could be a Certified Health IT Developer or an HIN/HIE when it provides access to its electronic health record (EHR) system to unaffiliated community providers, and the potential risk that EHR access terms or practices could subject the health system or provider to civil monetary penalties for information blocking.

A hospital or other health care provider is an actor subject to the new information blocking restrictions under the final rule issued by the ONC under the 21st Century Cures Act (Final Rule), but is not subject to information blocking civil monetary penalties unless it (1) is a Certified Health IT Developer (including as an offeror of certified health IT), or (2) operates an HIN/HIE in which more than two unaffiliated parties access, exchange or use EHI.

The software license agreements between many certified EHR vendors and their health system or other health care provider customer-licensees (EHR System Licensees) allow the EHR System Licensees to offer EHR system access to non-employed physician practices and other unaffiliated community providers for implementation and use in their physician office locations and other facilities. The EHR System Licensees typically provide access to their EHR systems as part of an agreement structured to meet the Stark Law exception and/or the federal anti-kickback statute safe harbor for EHR items and services, or waivers available under certain accountable care and other value-based care models. When the EHR System Licensee, its affiliated providers and community providers share an instance of the EHR system, they are able to access, exchange and use EHI created by any of the EHR system users, including the unaffiliated community providers. The offering of these EHR access arrangements may cause the EHR System Licensee to meet the definition of a Certified Health IT Developer and/or an HIN/HIE. We discuss this risk below. For more information about the Final Rule, please see our Special Report.

Certified Health IT Developers

The following sections address the Final Rule’s definition of a Certified Health IT Developer and questions that an EHR System Licensee should consider when evaluating whether an EHR access agreement could cause it to be Certified Health IT Developer.

What Is a Certified Health IT Developer?

The Final Rule defines a Certified Health IT Developer as follows:

• An individual or entity, other than a health care provider that self develops health IT for its own use, that develops or offers health information technology and which has, at the time it engages in a practice that is the subject of an information blocking claim, one or more Health IT Modules certified . . . pursuant to [the] ONC Health IT Certification Program…. (emphasis added)

The Final Rule does not clarify who is an “offeror” or what offeror activities would constitute “information blocking.” The Final Rule also fails to explain what it means for an offeror to “[have], at the time it engages in a practice that is the subject of an information blocking claim, one or more Health IT Modules certified . . . pursuant to [the] ONC Health IT Certification Program.”

An EHR System Licensee that is not the EHR vendor that sought and obtained the certification for the EHR software under the ONC Health IT Certification Program does not seem to “have . . . one or more Health IT Modules certified” and therefore arguably could never meet the definition of a Certified Health IT Developer. However, ONC’s preamble discussion of the definition is not clear on this point, and until ONC resolves the ambiguity, an EHR System Licensee that offers EHR system access to community providers should consider whether any of its EHR access agreement terms or other practices involving the access, exchange or use of EHI with community providers in connection with such agreements could constitute information blocking.

Is the EHR System Licensee a Certified Health IT Developer?

To assess whether an EHR System Licensee could be a Certified Health IT Developer, the EHR System Licensee should consider the following questions related to an offer of access to certified EHR technology to community providers:

1. Does the EHR System Licensee simply make portions of payments to an EHR vendor to enable community providers to license a separate instance of the EHR software (or other certified health IT) directly from an EHR vendor?
   • If so, then the EHR System Licensee may not be considered an “offeror” within the definition of a Certified Health IT Developer since the EHR vendor licenses the software directly to the community providers.
2. Does the EHR System Licensee offer to enter into an agreement with community providers under which community provider personnel may access and use the EHR System Licensee’s instance of the EHR system in the community provider’s offices or other facilities?
   • If the EHR System Licensee offers access to its EHR system, then the EHR System Licensee may be considered a Certified Health IT Developer based on the “offer.”

HINs and HIEs

The following sections discuss the Final Rule’s definition of an HIN/HIE, and questions that an EHR System Licensee should consider when evaluating whether an EHR access agreement could cause it to be an HIN/HIE.

What Is an HIN/HIE?

The Final Rule combines the definitions for HIN and HIE into one definition as follows:

• An individual or entity that 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 EHI:
  1. Among more than two unaffiliated individuals or entities (other than the individual or entity to which this definition might apply) that are enabled to exchange with each other; and
  2. That is for a Treatment, Payment or Health Care Operations purpose, as such terms are defined in the HIPAA regulations, regardless of whether such individuals or entities are subject to the HIPAA regulations.

An EHR System Licensee should evaluate whether its implementation of EHR access agreements to facilitate the exchange of EHI by or with community providers meets the above definition. For example, EHR System Licensees that provide EHR system access to community providers may implement security safeguards or procedures to control the flow of EHI among the community providers through the EHR system. The exercise of such control, even if to serve a legitimate privacy function that is not information blocking (e.g., preventing a community provider from accessing the EHI of non-patients in violation of HIPAA), could in turn cause the EHR System Licensees to meet the definition of an HIN/HIE.

Is the EHR System Licensee an HIN/HIE?

To assess whether an EHR System Licensee could be considered an HIN/HIE, the EHR System Licensee should consider the following questions:

1. Does the EHR System Licensee administer or control any policy, agreement or requirement that permits, enables or requires the use of technology (e.g., health information exchange functionality) that enables the exchange of EHI among more than two unaffiliated individuals or entities (not counting the EHR System Licensee)?
2. If the EHR System Licensee administers access to technology that enables more than two unaffiliated individuals or entities to exchange EHI, then is the exchange for Treatment, Payment or Health Care Operations (as each term is defined by the HIPAA regulations)?
   • For example, can the unaffiliated entities use the technology to exchange EHI with each other to coordinate the care they provide to a common patient? If yes, then the EHR System Licensee may be considered an HIN/HIE.

What Practices in Connection with Health IT Access Arrangements Raise Potential Information Blocking Concerns?

If the EHR System Licensee is a Certified Health IT Developer (as an offeror) or an HIN/HIE, then the EHR System Licensee should structure its agreements with community providers consistent with the information blocking exceptions under the Final Rule to avoid the risk of information blocking civil monetary penalties. For example, the EHR System Licensee should consider the following questions:

1. If an EHR System Licensee is a Certified Health IT Developer:
   • Does the EHR System Licensee host (in its data center or through a third party) the EHI created by or received on behalf of the community providers?
     • If the EHR System Licensee hosts the EHI, it could be in a position to exercise control over the EHI in ways that could implicate the information blocking prohibition.
     • Even if the EHR vendor hosts the EHR system and EHI, the EHR System Licensee may still be in a position to exercise control over the EHI (e.g., through its control of EHR system configuration settings) in ways that could implicate the information blocking prohibition.
   • Does the EHR System Licensee actually exercise control over some or all of the EHI created or received by the community provider in the certified health IT? For example, does the EHR System Licensee control the EHR system configuration settings that determine whether a particular user may access EHI in the EHR system?
     • Under the Final Rule preamble, ONC stated that an offeror could be subject to the information blocking prohibition with respect to EHI it “hold[s] or control[s].” If an EHR vendor holds or controls providers’ EHI, then an EHR System Licensee that is a Certified Health IT Developer because it offers access rights to community providers, but does not hold or control the EHI, would not, under ONC’s preamble discussion, seem to be in a position to engage in information blocking in its capacity as an offeror. Further, under a specific Cures Act provision, the EHR System Licensee would not be responsible for actions taken by the EHR vendor that could constitute information blocking.
2. Does the EHR System Licensee condition access to the EHR system (including, for example, its HIN/HIE functionality) on the community provider’s provision of intellectual property rights?
   • If yes, does the practice comply with the Final Rule’s Content and Manner Exception, Fees Exception or Licensing Exception? Note that under the Licensing Exception, actors may not require licensees or sublicensees (e.g., the community provider) to grant, assign or transfer to the actor any intellectual property of the licensee in return for the license or sublicense.
3. Does the EHR System Licensee’s EHR access agreement with a community provider address the disposition of records maintained within the EHR upon termination of the agreement?
   • Termination provisions that limit the community provider’s access, exchange or use of EHI post-termination could implicate the information blocking prohibition. (Likewise, a provision requested by the community provider that limits the EHR System Licensee’s access to the EHI may implicate the information blocking prohibition, since health care providers are subject to the prohibition. However, even if the community provider’s practice constitutes information blocking, it would not subject the community provider to civil monetary penalties because the community provider would be acting as a health care provider and not a Certified Health IT Developer or an HIN/HIE.)
4. Does the EHR System Licensee control the timing and implementation of bug fixes, upgrades and other software maintenance to the EHR system (including its HIN/HIE functionality)?
   • The Health IT Performance Exception permits actors in certain circumstances to inhibit the access, exchange or use of EHI for a limited period of time to perform planned or unplanned maintenance or updates. To comply with this exception, EHR System Licensees that control the timing and implementation of software maintenance or upgrades that could slow or cut off access to EHI should consider including service level agreement terms that establish a framework for limited planned and unplanned periods of maintenance in the EHR access agreement.

These are just some of the questions that health systems, hospitals and other health care providers potentially meeting the definition of a Certified Health IT Developer or an HIN/HIE should consider to ensure that they structure their EHR access agreements and conform their related practices in ways that mitigate potential information blocking civil monetary penalty exposure under the Final Rule.

Please contact your regular McDermott lawyer or any of the authors of this On the Subject if you have questions or need assistance with your compliance obligations under the Final Rule.

On April 21, 2020, the US Department of Health and Human Services (HHS) Office of the National Coordinator for Health Information Technology (ONC) and Centers for Medicare & Medicaid Services (CMS) announced that they will exercise discretion to delay enforcement of certain provisions of their final information blocking and interoperability rules beyond the compliance dates established by these rules. In addition, the HHS Office of Inspector General (OIG) announced a proposed rule amending its civil monetary penalty (CMP) regulations to incorporate new CMP authorities for information blocking.

The Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare & Medicaid Services (CMS) first displayed the contents of their information blocking and interoperability final rules on March 9, 2020. Those rules contained various compliance dates for new requirements that were tied to the publication date of the final rules in the Federal Register. After initially delaying the compliance dates by withholding the final rules from publication in the wake of the Coronavirus (COVID-19) public health emergency, the agencies have now announced that the final rules will be published in the Federal Register on May 1, 2020. ONC and CMS will then exercise discretion to delay enforcement of certain provisions beyond the compliance dates published in the final rules in recognition of the health care industry’s current focus on the ongoing COVID-19 public health emergency.

Importantly, the enforcement delays announced by ONC and CMS do not affect the substantive requirements of the final rules. For more information on the substance of the final rules, please see our Special Alert and our other On The Subjects here and here.

In this On The Subject, we discuss the new compliance dates of the ONC and CMS final rule requirements and review OIG’s proposed amendments to the CMP rules.

ONC Final Rule

ONC announced that it will exercise its discretion and not enforce the new certification requirements of its final rule until three months after each compliance date or timeframe identified in the ONC final rule. Along with the announcement, ONC published a helpful table outlining the compliance timeframes for each of these provisions and the effect of the enforcement delay. ONC did not extend the compliance date for the information blocking provisions of its final rule, but as discussed below OIG’s rulemaking will determine the timing of enforcement activity. Below, we provide the key compliance dates based on the enforcement delays announced by ONC:

• ONC will begin enforcing two of the new conditions of certification (CoCs) on September 30, 2020 (three months from the June 30, 2020, compliance date in the final rule):
  • Under the final rule, certified health IT developers may only prohibit or restrict communications by its customers about certified health IT under limited exceptions intended to allow the developer to reasonably protect its intellectual property. While developers must adhere to this CoC beginning September 30, 2020, they will have until March 31, 2021, to provide the required notice for the 2020 calendar year to customers stating that non-compliant confidentiality provisions or other restrictions or limitations on communications in existing contracts between the developer and the customer are invalid.
  • Certified health IT developers must ensure that their certified health IT conforms to the full scope of the certification criteria applicable to the developer, and that the developer has not taken any action to interfere with a user’s ability to access or use certified capabilities.
• ONC will enforce the following CoCs on February 1, 2021 (three months after the November 1, 2021, compliance date for these provisions in the final rule):
  • Certified health IT developers may not take any action that constitutes information blocking under the final rule.
  • Certified application programming interface (API) developers must meet the CoCs relating to API transparency (publicly publishing business and technical documentation), charge only permissible API fees and offer APIs on open and pro-competitive terms.
• ONC will enforce the following CoCs on August 1, 2022 (three months after the May 1, 2022, compliance date for these provisions under the final rule):
  • Certified health IT developers with currently certified APIs must meet the new API certification criteria, which includes implementation of the Fast Healthcare Interoperability Resources (FHIR) standard.
  • Certified health IT developers will by this date need to have updated their products to comply with the United States Core Data for Interoperability (USCDI) criteria.
• Certified health IT developers must submit initial plans for real-world testing to their certification bodies so that their certification bodies may evaluate the plan’s completeness and submit the plan to the ONC’s Certified Health IT Product List (CHPL) by March 15, 2021 (three months from the December 15, 2020 compliance date in the final rule). Certification bodies will be required to post certified health IT developers’ real-world testing results to the CHPL by June 15, 2022 (three months from the March 15, 2022, compliance date in the final rule).
• Certified health IT developers will be required to submit their initial attestation that they adhered to the CoCs effective during the period of September 30, 2020 – March 31, 2021 by July 30, 2021.
• Developers must meet the new electronic health information (EHI) export certification criterion by August 1, 2023 (three months after the May 1, 2023, compliance date under the final rule).

CMS Interoperability Final Rule

The CMS final rule requires Medicare Advantage plans, Medicaid state agencies, Medicaid managed care plans, CHIP agencies, CHIP managed care entities, and issuers of qualified health plans on federally-facilitated exchanges (Covered Plans and Agencies) to implement APIs that allow patient information to be shared more readily with third-party applications selected by patients. The new API requirement for Covered Plans and Agencies was scheduled to go into effect on January 1, 2021. However, CMS announced it will exercise enforcement discretion for the API requirement for a period of six months until July 1, 2021.

Notably, however, CMS announced that all other policies in the final rule concerning Covered Plans and Agencies will be implemented and enforced on schedule. Covered Plans and Agencies will therefore still be expected by January 1, 2022, to have the ability to, in response to a patient’s request, forward patient information electronically to other payors designated by a requesting patient for up to five years after the patient has disenrolled from the plan.

The CMS final rule also requires Medicare hospitals that have adopted electronic health record systems to, as a condition of participation (CoP) in the Medicare program, electronically report patient admissions, discharges, and transfers to patients’ primary care practitioners or other practitioners primarily responsible for the patient’s care. Originally, the final rule made the new CoP effective for hospitals six months following publication of the final rule. However, CMS announced that it has changed the text of the final rule to state that the CoP will now be effective May 1, 2021 (12 months after the final rule’s publication).

OIG Proposed CMP Rule Amendments

On April 21, 2020, OIG released a proposed rule amending its civil monetary penalty (CMP) regulations. Among other things, OIG’s proposed rule would incorporate statutory changes, including those related to new CMP authorities for information blocking, into OIG’s existing CMP regulations. OIG states that it intends for the proposed information blocking enforcement regulations to “improve coordination within the health care system and patients’ access to their health care data.”

Enforcement Timing

Consistent with ONC’s discussion in the preamble to its final rule, OIG states that it will not begin CMP enforcement before ONC’s information blocking compliance date (November 1, 2020). OIG also proposes that, in any event, it will not begin enforcement until at least 60 days after OIG issues a final rule. Conduct occurring between ONC’s compliance date and OIG’s effective date—if ONC’s compliance date occurs first—will not be subject to CMPs. Of note though, OIG is considering an alternative proposal that would establish an effective date on a date certain. OIG identifies October 1, 2020, as a date under consideration, but is also considering earlier or later dates. OIG is seeking comment on when it should begin enforcement and how various considerations, including the ongoing COVID-19 pandemic, should affect information blocking enforcement timing.

OIG Enforcement Priorities

OIG states that its proposed rule does not include new information blocking requirements, but instead seeks to formally incorporate ONC’s information blocking regulations as the basis for OIG imposing information blocking CMPs. OIG does, however, provide examples of how it plans to determine whether an actor’s practice resulted in one or many information blocking violations, which is relevant to determining the amount of potential penalties and is an area where the regulated industry is likely to have a significant interest in providing feedback.

Like other OIG authorities that include an intent element, OIG acknowledges that each information blocking allegation will require a facts and circumstances analysis, which OIG will conduct in coordination with ONC and the HHS Office for Civil Rights. In terms of enforcement priorities, OIG states that it will focus on investigating conduct that (1) involves patient harm; (2) impacts providers’ ability to deliver patient care; (3) continues for a long time; (4) results in financial loss for Medicare, Medicaid, and other federal health care programs as well as other government and private entities; and (5) involves an actor engaging in the conduct with “actual knowledge.”

The last focus area is noteworthy because the 21st Century Cures Act provides for CMPs to be issued in situations in which health IT developers, health information exchanges and health information networks “know” or “should know” that their practices are likely to interfere with the access, exchange or use of EHI. OIG seems to be saying that it plans to focus on a subset of conduct that it could otherwise pursue for CMPs. That said, OIG goes out of its way in the proposed rule to note that the stated priorities in the preamble guidance will not legally restrict OIG’s discretion to choose the complaints it investigates.

Public Comment

OIG seeks public comment on its proposed rule. Interested stakeholders will have 60 days from the date of the proposed rule’s publication in the Federal Register to submit comments, though OIG stated that it will monitor requests for an extended comment period due to the COVID-19 public health emergency. The proposed rule is scheduled for publication on April 24, 2020.

Please do not hesitate to contact your regular McDermott lawyer or any of the authors of this On The Subject if you have questions or need assistance with your compliance obligations under the ONC/CMS final rules or if you have questions or wish to comment on the OIG proposed rule.