The ONC recently released a proposed rule under the 21st Century Cures Act to promote interoperability of health IT and advance access, exchange or use of electronic health information. If finalized, the proposed rule would have significant implications for how health IT developers, health care providers and other stakeholders price access to APIs and other technology used to access, exchange or use health information. This On the Subject discusses the proposed framework for determining whether license fees and other charges for such technology would comply with the ONC’s proposed exceptions to the Cures Act’s information blocking prohibition and proposed Condition of Certification for APIs.

IN DEPTH

On March 4, 2019, the Office of the National Coordinator for Health Information Technology (ONC) published in the Federal Register its proposed rule under the 21st Century Cures Act to implement various policies to promote interoperability of health information technology (IT) and advance access, exchange or use of electronic health information (EHI) for continuity of care and other appropriate purposes. The proposed rule would amend the certification requirements under the ONC Health IT Certification Program and identify health IT pricing practices that do not fall under the Cures Act’s information blocking prohibition.

These proposed policies would have significant implications for how certified health IT developers, health care providers, health information exchanges (HIEs) and health information networks (HINs) (collectively, Actors) charge for licenses to use application programming interfaces (APIs); for other Interoperability Elements (as defined below); and for access, exchange or use of EHI with patients and other technology suppliers, health care providers and health plans. This On the Subject discusses the analytical framework for determining whether license fees and other charges for APIs and other Interoperability Elements used to access, exchange or use EHI would comply with the proposed rule’s information blocking exceptions and Condition of Certification for APIs.

Does the Information Blocking Prohibition Restrict Charges for Health IT Used to Access, Exchange and Use EHI?

The proposed rule generally defines information blocking to mean a practice by an Actor that is likely to interfere with, prevent or materially discourage access, exchange or use of EHI unless the practice is required by law or covered by an exception adopted by ONC. ONC proposes to define EHI to include data that is electronic protected health information (EPHI) under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) regulations, as well as other electronic individually identifiable health information.

Because of this broad definition of information blocking, any fees or other charges that an Actor charges patients, health care providers, health plans, technology suppliers or other third parties for access, exchange or use of EHI, or technology used for such access, exchange or use, potentially implicate the information blocking prohibition. In particular, ONC proposes that the information blocking prohibition apply to licensing Interoperability Elements, which are broadly defined to include all of the following:

• Any functional element of health IT, whether hardware or software, that could be used to access, exchange or use EHI for any purpose, including EHI transmitted by or maintained in disparate media, information systems, HIEs or HINs

• Any technical information that describes the functional elements of technology (such as a standard, specification, protocol, data model or schema) and that a person of ordinary skill in the art may require to use the functional elements of the technology, including for the purpose of developing compatible technologies that incorporate or use the functional elements

• Any technology or service that may be required to enable the use of a compatible technology in production environments, including but not limited to any system resource, technical infrastructure, or HIE or HIN element

• Any license, right or privilege that may be required to commercially offer and distribute compatible technologies and make them available for use in production environments

• Any other means by which EHI may be accessed, exchanged or used

ONC is likely to consider any pricing practice that involves an Interoperability Element as potentially interfering with access, exchange or use of EHI and, as such, potentially subject to the information blocking prohibition. Those practices, unless required by law, would need to fit within an information blocking exception.

What Information Blocking Exceptions Protect Licensee Fees and other Charges for Health IT Used to Access, Exchange and Use EHI?

The proposed rule includes the following exceptions for license fees and other charges for Interoperability Elements and other fees that may interfere with EHI access, exchange or use:

• Licensing of Interoperability Elements on Reasonable and Non-discriminatory Terms (Licensing Interoperability Element Exception)

• Exception for Recovering Costs Reasonably Incurred to Provide Access, Exchange or Use of EHI (Cost Recovery Exception)

A fee or other pricing practice that meets the definition of information blocking must satisfy at least one of these exceptions.

Licensing Interoperability Elements Exception

The proposed Licensing Interoperability Elements Exception would permit a certified health IT developer or other Actor to charge a fee for the use of an Interoperability Element that satisfies all of the restrictions of the proposed exception. The key restriction is that the Actor must base the fee solely on the independent value of the Actor’s technology to the licensee’s products. The fee must not be based on any strategic value stemming from the Actor’s control over essential means of accessing, exchanging or using EHI. Further, the Actor must not price the Interoperability Element based on the revenue or other value that the licensee may derive from access, exchange or use of EHI obtained via the Interoperability Elements, including the secondary use of EHI. A complete list of the restrictions directly applicable to the fees is available in the below chart.

This exception also requires health IT developers that are API Technology Suppliers to comply with a proposed new Condition of Certification when charging fees to API Data Suppliers or API Users (discussed further below).

• An API Technology Supplier is a health IT developer that creates the API technology that is presented for testing and certification to any of the certification criteria adopted or proposed for adoption at 45 CFR § 170.315(g)(7) through (g)(11).

• An API Data Provider is the organization that deploys the API technology created by the API Technology Supplier and provides access via the API technology to data it produces and electronically manages. In some cases, the API Data Provider may contract with the API Technology Supplier to perform the API deployment service on its behalf. However, in such circumstances, the API Data Provider retains control of what information is disclosed and how it is disclosed, and therefore for the purposes of this definition is considered to be the entity that deploys the API technology.

• An API User is a person or entity that uses or creates software applications that interact with the APIs developed by the API Technology Supplier and deployed by the API Data Provider. API Users include, but are not limited to, third-party software developers, developers of software applications used by API Data Providers, patients, health care providers, and payers that use apps or services that connect to API technology on their behalf.

Cost Recovery Exception

ONC proposes the Cost Recovery Exception to allow an Actor to recover the costs that it reasonably incurs to provide access, exchange or use of EHI plus a reasonable profit. As with the other exceptions, an Actor must comply with specific restrictions to meet the exception. For example, the pricing methodology used to recover the costs must be based on objective and verifiable criteria, uniformly applied for similarly situated people/requests; be reasonably related to the Actor’s costs; be reasonably allocated among relevant customers; not be based on competitive considerations; and not be based on sales, profit, revenue or other value that the requestor or other party may derive from the access, exchange or use (including secondary use) that exceeds the Actor’s reasonable costs for providing such access, exchange or use of EHI.

Additionally, ONC would explicitly exclude certain costs from protection under the exception such as the following:

• Fees prohibited under the HIPAA Privacy Rule for individuals’ requests for access to their protected health information

• Fees based in any way on electronic access by individuals (or their personal representatives, agents or designees) to the individual’s EHI

• Fees to export EHI to switch health IT or provide EHI to patients, if done through a capability certified to the new certification criterion concerning EHI export capability (discussed below)

• Fees to export or convert data from an EHR, unless the parties had agreed to the fee at the time the EHR was acquired

The below chart includes a complete list of the specifically excluded costs, as well as other restrictions directly affecting pricing.

Like the Licensing Interoperability Elements Exception, this exception requires API Technology Suppliers to comply with proposed new conditions of certification for certified APIs. This exception also imposes the API Condition of Certification fee restrictions on API Data Providers.

How does the proposed Condition of Certification for APIs affect license fees and other charges?

ONC proposes to adopt a Condition of Certification for APIs that restricts the pricing practices of certified health IT developers that are API Technology Suppliers. The Condition of Certification limits API Technology Suppliers to charging fees that fall into one of three categories:

• Fees to recover reasonably incurred development, deployment and upgrade costs

• Fees to recover reasonably incurred incremental costs for supporting use of the API for purposes other than patient access, subject to certain limitations

• Fees for value-added services supplied in connection with software that can interact with the API as long as those services are not necessary to develop or deploy the software

Under the Condition of Certification, all fees charged by an API Technology Supplier must also meet general conditions aimed at ensuring that the fees are based on objective and verifiable criteria that are uniformly applied; are reasonably related to the API Technology Supplier’s costs, which must be reasonably allocated among all relevant customers; and are not based on competitive considerations. A complete list of the conditions applicable to pricing practices is included in the below chart.

As noted above, the Cost Recovery Exception to the information blocking prohibition would also impose the API Conditions of Certification fee limitations on an API Data Provider (e.g., a hospital that licenses EHR software with an API), even if the API Data Provider is not a certified health IT developer.

What is the Analytical Framework for Determining Whether Charges for Health IT comply with an information blocking exception under the proposed rule and, if applicable, the Condition of Certification for APIs?

If an Actor desires to impose a fee or other charge for an Interoperability Element or EHI access, exchange or use, it must design the fee to meet an exception to the information blocking prohibition and any applicable conditions of certification for certified health IT, such as the restrictions on fees for certified APIs. Accordingly, the Actor should consider the following questions:

• EHI. Does the proposed fee or other charge relate to EHI, as opposed to HIPAA de-identified health information or other information outside the definition of EHI?

• Technology or Practice. Is the proposed fee or other charge for a license or other right to use an Interoperability Element, or for providing access, exchange or use of EHI? For example, is the fee in exchange for a license for an API that enables access to EHI stored in an EHR system? Alternatively, is the fee for a license to elements of EHR software or other health IT that stores EHI rather than providing access, exchange or use of EHI?

• Information Blocking Exception. Does the proposed pricing practice meet either the Interoperability Element Exception or the Cost Recovery Exception? The Interoperability Element Exception is typically more attractive if the applicable costs are low, so it may be advantageous to consider that exception first.

• Additional Requirements for Certified APIs. If the proposed fee relates to a certified API, does the proposed pricing practice meet the additional Condition of Certification for APIs?

Summary Chart

The following chart identifies all of the restrictions directly applicable to fees charged by an Actor under the proposed rule. The first column of the chart identifies a restriction affecting fees. The second column indicates whether the restriction in the first column is an element of the Licensing Interoperability Element Exception. The third column indicates whether the restriction in the first column is an element of the Cost Recovery Exception. The fourth column indicates whether the restriction applies to developers of certified APIs, and the fifth column indicates whether the restriction applies to export capabilities of health IT certified to certification criterion at § 170.315(b)(10).

Capitalized terms used in the chart have the meanings given to them by the proposed rule or the HIPAA administrative simplification regulations.

Click here to view the full chart.