The Office of the National Coordinator for Health Information Technology recently released a final rule under the 21st Century Cures Act to promote interoperability of health IT and advance access, exchange or use of electronic health information (EHI). The final rule has significant implications for how health IT developers, health care providers and other stakeholders price access to application programming interfaces (APIs) and other technology used to access, exchange or use EHI. This On the Subject discusses the framework for determining whether license fees and other charges for use of such technology would comply with the final rule’s exceptions to the Cures Act’s information blocking prohibition and condition of certification for certified APIs.
On March 9, 2020, the Office of the National Coordinator for Health Information Technology (ONC) released its final 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 final rule amends the certification requirements under the ONC Health IT Certification Program and identifies health IT pricing practices that do not fall under the Cures Act’s information blocking prohibition.
These final policies have significant implications for how certified health IT developers, health care providers, health information networks (HINs) and health information exchanges (HIEs) (collectively, actors) license and charge for technology to enable access, exchange or use of EHI with patients and other technology and service providers, health care providers and health plans.
Subject to limited exceptions, EHI covered by the information blocking prohibition includes electronic protected health information under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) regulations (EPHI) to the extent that the EPHI is part of a patient’s electronic medical record or another designated record set under HIPAA, regardless of whether the records are used or maintained by or for a HIPAA covered entity. However, until the date 24 months after the publication of the final rule in the Federal Register, EHI is limited to the data elements represented in the US Core Data for Interoperability (USCDI) standard adopted under the health IT certification provisions of the final rule.
This On the Subject discusses the analytical framework for determining whether license fees and other charges for use of application programing interfaces (APIs) and other technology used to access, exchange or use EHI comply with the final rule’s information blocking exceptions and condition of certification for certified APIs. It also recommends practical next steps for implementing the final rule’s fee restrictions.
For more information about the final rule, including provisions that are not directly related to fees and other charges, see McDermott’s prior Special Reportcomprehensively covering the information blocking provisions of the final rule.
Does the information blocking prohibition restrict charges for health IT used to access, exchange and use EHI?
The final 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 in the final rule. Because of this broad definition, any fees or other charges that an actor charges patients, health care providers, health plans, technology or service providers or other third parties for access, exchange or use of EHI or technology to enable such access, exchange or use, potentially implicate the information blocking prohibition. Consequently, those fees and charges, unless required by law, would need to fit within an information blocking exception to protect the actor from potential information blocking liability.
What information blocking exceptions protect licensee fees and other charges for use of health IT used to access, exchange and use EHI?
The final rule includes the following three exceptions for license fees and other charges for interoperability elements and other fees for use of technology that may interfere with EHI access, exchange or use. A fee or other charge that meets the definition of information blocking must satisfy at least one of these exceptions:
Content and Manner Exception
Content and Manner Exception
The Content and Manner Exception allows an actor and a party that requests EHI to negotiate mutually agreeable terms (including fees) for access, exchange and use of EHI. To be protected under the Content and Manner Exception, the actor must respond to a request for EHI with the subset of EHI identified by the USCDI data elements until the date 24 months after the publication of the final rule in the Federal Register. After that date, actors must respond with all EHI in a designated record set as discussed above.
In terms of the manner of response, an actor must fulfill a request for access, exchange or use of the required content in the manner requested, unless (1) the actor cannot technically fulfill the request, or (2) the actor and requestor are unable to reach mutually agreeable terms. If an actor fulfills a request in the manner requested, the limitations in the Fee Exception and Licensing Exception would not apply. Thus, the actor would have the opportunity to negotiate mutually agreeable fees and other terms with requestors.
If the actor does not fulfill a request in the requested manner, then the actor must fulfill the request in one of three alternative manners specified in the exception without unnecessary delay. When an actor fulfills a request in an alternative manner, the fees charged would have to meet the Fees Exception or the Licensing Exception.
The Fees Exception allows an actor to charge fees, including those that result in a reasonable profit margin, for accessing, exchanging or using EHI, provided that the fee is:
Based on objective and verifiable criteria, uniformly applied for similarly situated people/requests;
Reasonably related to the actor’s costs;
Reasonably allocated among all similarly situated people; and
Based on costs not already recovered for the same instance of the service to a provider or third party.
In addition, the fee must not be based on:
Sales, profit, revenue or other value that the requestor or other party may derive from the access, exchange or use of the EHI;
Costs that an actor incurs because it designed or implemented health IT in non-standard ways (unless the requestor agreed to the fee associated with such implementation);
Costs associated with intangible assets other than actual development and acquisition costs;
Opportunity costs unrelated to the access, exchange or use of EHI; or
Any costs leading to the creation of intellectual property if the actor charges a royalty for that intellectual property under the Licensing Exception and the royalty includes development costs of creating that intellectual property.
Additionally, an actor may not charge any of the following fees under the Fees Exception:
Fees prohibited under the HIPAA Privacy Rule for individuals’ requests for access to their protected health information;
Fees based in any way on the electronic access of an individual’s EHI by the individual, the individual’s personal representatives or others designated by the individual (The final rule defines “electronic access” as “an internet-based method that makes EHI available at the time the EHI is requested and where no manual effort is required to fulfill the request.” So whenever fulfilling individuals’ requests to send EHI to themselves or their personal representatives or others they designate, if the process requires manual effort, such as collating or assembling electronic health records from multiple systems, then the definition of electronic access would not be met and the actor could charge a fee and meet the Fees Exception.);
Fees to export EHI to switch health IT or provide EHI to patients, if done through a capability certified to the final rule’s EHI export health IT certification criterion at 45 CFR § 170.315(b)(10) (Certified EHI Export Capability); and
Fees to export or convert data from an EHR system, unless the parties agreed to the fee in writing at the time the EHR system was acquired.
In addition, this exception requires health IT developers that create certified API technology (certified API developers) to comply with the new condition of certification for certified APIs as a condition of meeting the Fees Exception.
Under the Licensing Exception, an actor’s terms (including those related to fees) for licensing an interoperability element for EHI to be accessed, exchanged or used is not prohibited information blocking when the practice meets all of the conditions discussed below. The final rule defines the term “interoperability element” to mean “hardware, software, integrated technologies or related licenses, technical information, privileges, rights, intellectual property, upgrades, or services that (1) may be necessary to access, exchange or use EHI and (2) are controlled by the actor. Such control includes the ability to confer all rights and authorizations necessary to use the element to enable the access, exchange or use of EHI.”
Upon receiving a request to license an interoperability element for the access, exchange or use of EHI, the actor must begin license negotiations with the requestor within 10 business days from receipt of the request and negotiate a license with the requestor, subject to the licensing conditions below (and other requirements of the Licensing Exception), within 30 business days from receipt of the request. The license for the interoperability element must meet the following conditions:
Scope of Rights. The license must provide all rights necessary to: enable the access, exchange or use of EHI and to achieve the intended access, exchange or use of EHI via the interoperability element.
Reasonable Royalty. If the actor charges a royalty for the use of the interoperability element, the royalty must be reasonable and comply with the following requirements:
The royalty must be non-discriminatory, consistent with the non-discriminatory terms requirement below.
The royalty must be based solely on the independent value of the actor’s technology to the licensee’s products, not on any strategic value stemming from the actor’s control over essential means of accessing, exchanging or using EHI.
If the actor has licensed the interoperability element through a standards developing organization in accordance with its policies regarding the licensing of standards-essential technologies on terms consistent with the licensing exception, the actor may charge a royalty that is consistent with such policies.
An actor may not charge a royalty for intellectual property if the actor recovered any development costs pursuant to the Fees Exception that led to the creation of the intellectual property.
In the final rule preamble, ONC notes that whether a royalty is reasonable for purposes of the Licensing Exception requirement depends on the particular facts and circumstances. ONC also identifies the following non-exclusive list of potential factors for evaluating reasonableness:
The royalties received by the actor for the licensing of proprietary elements in other circumstances comparable to reasonable and non-discriminatory licensing circumstances.
The rates paid by the licensee for the use of other comparable proprietary elements.
The nature and scope of the license.
The effect of the proprietary elements in promoting sales of other products of the licensee and the licensor, taking into account only the contribution of the elements themselves and not of the enhanced interoperability that they enable.
The utility and advantages of the actor’s interoperability element over the existing technology, if any, that had been used to achieve a similar level of access, exchange or use of EHI.
The elements’ contribution to the technical capabilities of the licensee’s products, taking into account only the value of the elements themselves and not the enhanced interoperability that they enable
The portion of the profit or selling price that may be customary in the particular business or in comparable businesses to allow for the use of the proprietary elements or analogous elements that are also covered by reasonable and non-discriminatory terms commitments.
The portion of the realizable profit that should be credited to the proprietary elements as distinguished from non-proprietary elements; the manufacturing process; business risks; significant features or improvements added by the licensee; or the strategic value resulting from the network effects, switching costs, or other effects of the adoption of the actor’s technology.
The opinion testimony of qualified experts.
The amount that a licensor and a licensee would have agreed upon (at the time the licensee began using the elements) if both were considering the reasonable and non-discriminatory terms obligation under the Licensing Exception and its purposes, and had been reasonably and voluntarily trying to reach an agreement.
Non-Discriminatory Terms. The royalty and other terms on which the actor licenses and otherwise provides the interoperability element must be non-discriminatory and comply with the following requirements:
The terms must be based on objective and verifiable criteria that are uniformly applied for all similarly situated classes of persons and requests.
The terms must not be based in any part on:
Whether the requestor or other person is a competitor or potential competitor, or will be using EHI obtained via the interoperability elements in a way that facilitates competition with the actor; or
The revenue or other value the requestor may derive from access, exchange or use of EHI obtained via the interoperability elements.
Accordingly, the royalty or other compensation terms in the license agreement for the interoperability element may not be a revenue share based on the revenue that the licensee generates from EHI transferred through the interoperability element.
How does the condition of certification for APIs affect license fees and other charges?
ONC finalized a condition of certification for certified APIs that includes, among other requirements, restrictions on the pricing practices of certified API developers. The requirements directly applicable to the fee restrictions are as follows:
Permitted Fees Generally. The condition of certification permits certified API developers to charge three categories of permitted fees and expressly allows the permitted fees to include a reasonable profit margin otherwise in accordance with the Fees Exception. All other fees related to certified API technology are prohibited. A certified API developer must ensure that:
All permitted fees are based on objective and verifiable criteria that are uniformly applied to all similarly situated hospitals, physician practices and other organizations that deploy certified API technology (API information sources), and persons or entities that create or use software applications that interact with the certified API technology (API users).
Permitted fees imposed on API information sources are reasonably related to the certified API developer’s costs to supply certified API technology to, and if applicable, support certified API technology for, API information sources.
Permitted fees to supply and support certified API technology are reasonably allocated among all similarly situated API information sources.
Fees are not based on whether API information sources or API users are competitors or potential competitors, or will use the API in a way that facilitates competition with the certified API developer.
Three Categories of Permitted Fees. The condition of certification permits the following categories of fees for certified API technology:
Permitted Fee: Development, Deployment and Upgrades. A certified API developer may charge fees to an API information source to recover the costs reasonably incurred by the certified API developer to develop, deploy and upgrade certified API technology.
Permitted Fee: Recovering API Usage Costs. A certified API developer may charge fees to an API information source related to the use of certified API technology, provided that the fees are limited to the recovery of incremental costs reasonably incurred by the certified API developer when it hosts certified API technology for the health care provider or other API information source.
Permitted Fee: Value-Added Services. A certified API developer may charge fees to an API user for value-added services related to certified API technology, as long as the services are not necessary to efficiently and effectively develop and deploy production-ready software that interacts with the certified API technology.
Prohibited Fees. Consistent with the Fees Exception, the condition of certification prohibits a certified API developer from charging a fee for:
Costs associated with intangible assets other than actual development or acquisition costs of such assets;
Opportunity costs unrelated to the access, exchange or use of EHI; and
Any costs that led to the creation of intellectual property if the actor charged a royalty for that intellectual property pursuant to the Licensing Exception and the royalty included the development costs for the creation of the intellectual property.
Non-Discrimination. A certified API developer must meet the following non-discrimination requirements when setting fees and other terms with respect to certified API technology:
Provide the certified API technology to an API information source on terms that are no less favorable than the certified API developer provides to itself and its own customers, suppliers, partners and other persons with whom it has a business relationship;
Base the terms for the provision of certified API technology on objective and verifiable criteria that are uniformly applied to all substantially similar or similarly situated classes of persons and requests;
Not offer different terms or services based on whether a competitive relationship exists or would be created; and
Not offer different terms or services based on the revenue or other value that another party may receive from using the API technology.
Description of API Fees. The certified API developer must describe all fees that it charges for the use of its certified API technology in detailed, plain language. The description must include all material information, including the persons or classes of persons to whom the fee applies; the circumstances in which the fee applies; and the amount of the fee, which for variable fees must include the specific variables and methodologies used to calculate the fee.
Record-Keeping Requirements. A certified API developer must keep detailed records of any fees charged with respect to the certified API technology, the methodologies used to calculate the fees and the specific costs to which such fees are attributed. In the final rule preamble, the ONC states it expects that “the accounting practices already used by health IT developers will largely support the health IT developer to meet this requirement. Examples of these practices by health IT developers include the methods used to track their own investments, determine how to bill and issue invoices to their customers, document receipt of payment, and to maintain overall accurate financial records of business transactions.”
What is the analytical framework for determining whether charges for health IT comply with an information blocking exception under the final rule and, if applicable, the condition of certification for APIs?
If an entity desires to impose a fee or other charge for an interoperability element or EHI access, exchange or use, to the extent the information blocking prohibition applies, the entity 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 entity should consider the following questions:
Covered Actor. Is the entity seeking to charge the license fees or other charges for use of APIs and other technology to access, exchange or use EHI an actor subject to the final rule (i.e., a health care provider, certified health IT developer, or an HIN or HIE)?
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, such as (for the 24 months after the publication of the final rule in the Federal Register), information that is not included in the USCDI data set?
Interoperability Element or Access, Exchange or Use. Is the proposed fee or other charge for (1) a license or other right to use an interoperability element or (2) 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? Is the fee for a license to elements of EHR software or other health IT that only stores EHI rather than providing access, exchange or use of EHI? Alternatively, is the fee for participation in an HIN or HIE?
Information Blocking Exception. Does the proposed fee or other charge meet the Content and Manner Exception, Fees Exception or Licensing Exception? The Content and Manner Exception provides the greatest flexibility for actors relative to pricing and terms and may, therefore, be the most advantageous exception for actors to consider first. Between the Licensing Exception and the Fees Exception, the Licensing Exception is typically more attractive if the applicable costs are low, so it may be advantageous to consider that exception before the Fees Exception.
Additional Requirements for Certified API Technology. If the proposed fee or other charge relates to a certified API, does the proposed pricing practice meet the additional requirements of the condition of certification for APIs?
What are the key next steps for a certified health IT developer to ensure fees and other charges comply with the final rule’s information blocking prohibition and condition of certification for certified APIs?
A certified health IT developer should consider at least the following key steps to implement compliance.
Step 1: Identify all executed and template contracts and other arrangements under which the developer provides technology that includes any capability or service that enables access, exchange or use of EHI to third parties rather than merely storing EHI.
Step 2: Develop a business strategy and process for amending non-compliant arrangements with current customers and other counter-parties within the six-month period before the final rule’s compliance date for its information blocking provisions and for negotiating market terms with prospective counter-parties under the arrangements identified in Step 1 in accordance with the Content and Manner Exception.
Step 3: Revise any template pricing terms that do not meet the restrictions of the Fees Exception or Licensing Exception in order to be prepared for the failure of negotiations of market terms in accordance with the Content and Manner Exception.
Step 4: Develop a business process for responding to third-party requests to license an interoperability element, including its deadlines for beginning license negotiations and completing negotiations of a license agreement.
Step 5: Ensure that any template license or other agreement with a new customer for an EHR system specifies any fees to export or convert data from the EHR system in order to avoid the prohibition on export and conversion fees that are not agreed to in writing at the time the EHR system is acquired.
Step 6: Determine how to reasonably allocate certified API supply and support costs among similarly situated API information sources, including determining reasonably likely costs and forecasting the number of API information sources deploying the certified API.
Step 7: Determine whether existing accounting practices maintain detailed records of fees charged with respect to the certified API and other technology, the methodologies used to calculate the fees and the specific costs to which such fees are attributed. If existing practices do not maintain detailed records of these items, establish a practical business process to attribute fees to costs and a record keeping system to track required information.
What are the key next steps for a health care provider (that is not a certified health IT developer) to ensure that its contracts and other arrangements comply with the fee restrictions in the final rule’s exceptions to the information blocking prohibition?
A hospital, physician practice or other health care provider actor should consider the following steps to implement compliance with the information blocking prohibition:
Step 1: Identify all contracts and other arrangements under which the health care provider licenses or otherwise obtains an interoperability element or service from a certified health IT developer or other actor that enables access, exchange or use of EHI rather than merely storing EHI.
Step 2: Evaluate the arrangements identified under Step 1 to determine whether any fees may fail to meet the limitations imposed under the applicable final rule exception, and if so, consider requesting modified pricing terms for non-compliant arrangements.
Step 3: Develop a business strategy and process for responding to requests from physician practices and other health care provider requestors that have common patients with the health care provider receiving the request, for access, exchange or use of EHI maintained by the receiving health care provider. For example, a community physician practice may request that a hospital with common patients establish a custom interface to enable seamless access to EHI about common patients maintained by the hospital.
Our summary chart, available here, identifies all of the restrictions directly applicable to fees charged by an actor under the final rule. The first column of the chart identifies a restriction affecting fees. The second column indicates whether the fee restriction in the first column is an element of the Licensing Exception. The third column indicates whether the restriction in the first column is an element of the Fees Exception. The fourth column indicates whether the restriction applies to developers of certified APIs.
*For more information about elements of the exceptions that are not directly related to fees charged by an actor, please see McDermott’s prior Special Report comprehensively covering the information blocking provisions of the final rule.
Please do not hesitate to contact your regular McDermott lawyer or any one of the authors of this On the Subject if you have questions or need assistance with understanding the fee restrictions under the final rule.