Kaleidoscope Blog
Would Health IT APIs Become A Public Utility Under The ONC’s Proposed Rules?

Would Health IT APIs Become a Public Utility under the ONC’s Proposed Rules?

The Cures Act directs the Office of the National Coordinator for Health IT (ONC) to implement Conditions and Maintenance of Certification that require EHR vendors to provide open APIs without special effort.  In its proposed rule, the ONC not only proposes technical standards and technical outcome expectations to facilitate access, exchange and use of electronic health information using FHIR-based APIs; it also takes direct aim at rent-seeking business practices and behaviors that it believes interfere with data interoperability.  This blog reviews the ONC proposal to restrict the fees that health IT developers would be permitted to charge for their certified API technologies, and offers some thoughts about the impact the fee proposals could have in the market.

Background

The ONC’s proposal to regulate fees on API technology would apply to EHR vendors, which would be required to implement the proposed certification criterion for FHIR-based “standardized API for patient and population services” within 24 months after final rules take effect.  Other health IT vendors have the option of presenting API technologies to the ONC for testing and certification under the ONC Health IT Certification Program.  API Technology Suppliers with certified API technologies would be subject to proposed Conditions and Maintenance of Certification, starting at as new 45 C.F.R. 170.400.  Section 170.404 of the proposed Conditions and Maintenance of Certification addresses APIs, and includes conditions on the fees that API Technology Suppliers would be permitted to charge.

Guiding Questions, While Reviewing the ONC’s Proposal:

  1. Would the fee proposals, if implemented, move API-enabled HIT towards a more regulated marketplace, similar to a public utility? Would a regulated marketplace be appropriate before API-enabled interoperability of electronic health information has had a chance to mature?
  2. Do the fee proposals exceed the ONC’s interpretive authority to implement the Cures Act?
  3. Which technology companies would benefit most under the fee proposal? Would the fee proposals advantage some technology companies over others, and make it more difficult for new digital health innovators to enter the market?
  4. Would the fee proposals help or hinder an open and competitive marketplace that is already moving toward self-serve, on-demand software-as-a-service (or platform-as-a-service) offerings?

Summary

Absent a valid exception, the API Conditions of Certification would prohibit API Technology Suppliers from imposing fees associated with certified API technology.  Exceptions for permitted fees must meet general and specific conditions.

General Conditions

To qualify for an exception, all permitted fees must:

  • Be based on objective and verifiable criteria, uniformly applied for all substantially similar or similarly situated classes of persons and requests
  • Not be based on whether the API User is a competitor or potential competitor, or on whether the data accessed via the API technology would be used to facilitate competition with the API Technology Supplier
  • Be reasonably related to the API Technology Supplier’s costs of supplying and supporting the API technology
  • Be reasonably allocated among all customers of the vendor’s API technology

In addition, all API Technology Suppliers would be subject to record-keeping requirements.  These requirements would require API Technology Suppliers to keep for inspection “detailed records of any fees charged for its certified API technology, including the methodologies used to calculate these fees, and the specific costs attributed to these fees.”  These record-keeping requirements could last for up to 10 years under other provisions of the proposed rule.

Permitted Fees to API Data Providers

Recovery of Reasonably Incurred Costs to Develop, Deploy or Upgrade API Technology.

API Technology Suppliers would be permitted to charge fees to API Data Providers to “recover the costs reasonably incurred by the API Technology Supplier to develop, deploy and upgrade API technology for the API Data Provider.”  Note that these fees must be tied to costs reasonably incurred to development, deployment or upgrade activities, and can only be charged to the API Data Provider.  In its preamble to the proposed rule, the ONC states that it would be “inappropriate to pass development, deployment or upgrade fees to API Users”.  Doing so would encourage cost shifting, which could interfere with access to electronic health information through APIs “without special effort”, in the ONC’s view.  Instead, ONC believes these costs should be negotiated directly between the API Data Provider and the API Technology Supplier.  If API User or other parties want to pay these fees for an API Data Provider, they would not be prohibited from doing so under the proposed rule, according to the ONC in its commentary.

Recovery of Reasonably Incurred Costs to Support the Use of API Technology.

API Technology Suppliers would be permitted to charge usage fees to API Data Providers, except where the API technology is used to facilitate a patient’s ability to access, exchange or use their electronic health information.   These fees would have to be tied to “incremental costs reasonably incurred by the API Technology Supplier to support the use of API technology deployed by or on behalf of the API Data Provider.”  In its commentary, the ONC notes that revenue-sharing or royalty arrangements would likely not be permitted fees because they do not bear any plausible relation to the costs incurred for providing support for the API technology.  The ONC also cautions API Technology Suppliers to make sure that their pricing structures, whether they be tiered, “pay-as-you-go” or “flat fee”, are plausibly connected to the “incremental costs reasonably incurred” so that API Data Providers are not overcharged.  Even a pricing model with unlimited API call volume would need to be based upon a realistic estimate of anticipated volume to avoid excessive fees.

The proposed rule would also disallow API Technology Suppliers from recovering costs associated with intangible assets or opportunity costs.  In the ONC’s view, “it would be inappropriate to permit an actor to charge a fee based on these considerations, which are inherently subjective and could invite the kinds of rent-seeking and opportunistic pricing practices that create barriers to access, use and exchange of EHI and impede interoperability.”  However, the ONC would accept the reasonable forward-looking cost of capital as an incremental cost reasonably incurred.

Value-Added Services Charged to API Users.  API Technology Suppliers would be permitted to charge fees to API Users for value-added services. These services would need to be provided in connection with and supplemental to the development, testing and deployment of software applications that interact with API technology.  Examples might include:

  • advanced training
  • premium development tools
  • premium distribution channels
  • enhanced compatibility/integration testing assessment
  • “write” access to APIs
  • co-branded integration into the API Technology Supplier’s product(s) workflow
  • co-marketing arrangements
  • promoted placement in an API Technology Supplier’s app store

Prohibited Fees.

In its discussion of pricing for API technologies, the ONC preamble provides examples of fees that would be inappropriate because they create barriers to entry or competition.  They include:

  • any fee for access to the documentation that an API Technology Supplier is required to publish or make available under the API Condition of Certification
  • any fee for access to other types of documentation or information that a software developer may reasonably require to make effective use of API technology for any legally permissible purpose
  • Any fee in connection with any services that would be essential to a developer or other person’s ability to develop and commercially distribute production-ready applications that use API technology.
    • For example, charging fees for access to “test environments” and other resources that an app developer would need to efficiently design and develop apps would not be a permitted “value added service”, in the ONC’s view.
    • Another example: charging access fees to connect to FHIR services or have the ability to dynamically register with an authorization server would not be a permitted “value added service”, in the ONC’s view.

Unlike the permitted fee exceptions proposed in the API Conditions and Maintenance of Certification, these examples do not address the amount of fees that can be charged.  A question to consider is whether the ONC can do enough to curb rent-seeking and other opportunistic behaviors if it limited its fee proposal to these kind of qualitative requirements, instead of regulating the  the amount of fees that can be charged.

Take-Aways and Thoughts

  1.  The proposed fees regulations, if implemented, would impact Health IT vendors of certified EHRs (CEHRTs) the most, along with the healthcare providers that use CEHRTs under CMS’ Promoting Interoperability Program (formerly, the Medicare and Medicaid EHR Incentive Program).  By limiting fees to narrowly permissible activities; tying the amount of these fees to the costs reasonably incurred; imposing record-keeping requirements; and requiring that fees (other than “value added service” fees) be negotiated directly with the API Data Providers — the ONC is driving to the heart of rent-seeking activities that have contributed to information blocking in the marketplace, to date, and does not seem interested in wasting any time in its efforts to deter these activities.
  2. Health IT vendors that are not required to deliver certified products would not be impacted, but an open question remains:  Will the ONC’s proposals, as a whole, drive the market inexorably towards certification?  Or, would it instead influence the market with its requirements?
  3. In particular, API Data Providers, as purchasers of CEHRTs, would likely shift their expectations about API technologies, and be influenced by the ONC’s pricing and other proposals as they develop roadmaps for procuring API technologies.
  4. Other API purchasers are also likely to follow suit.  The ONC’s broader proposed Information Blocking regulation, (discussed starting at page. 7508 in the 84 Fed Reg 7424 (March 4, 2019)) not only applies to health IT vendors of certified health IT,  but to health care providers, health information exchanges and health information networks.
  5. Even more broadly, the ONC’s proposed rules could influence API procurement by payers and state benefit programs.  In a related rulemaking from CMS, Medicare Advantage organizations, Medicaid Managed Care Organizations, state Medicaid and CHIP agencies, and qualified health plans in the ACA Marketplaces  would be required to make data available to patients through APIs “without special effort”.  While not directly applicable to them, the API Conditions and Maintenance of Certification could become an informal roadmap for them when they procure API technologies.
  6. Technology giants and other digital health innovators deliver API capabilities through software-as-as-service and platform-as-a-service business models, and generate recurring subscription revenue from these offerings.  Under these models,  software applications trend towards on-demand, self-serve enterprise service agreements, and service-specific terms.  APIs are a necessary capability for providing these modular contract stacks, but an open question is whether API-based data interoperability can be efficiently and effectively accounted for, or should be separately defined within these broader, modular offerings.
  7. A related question goes to the heart of the ONC’s authority to broadly interpret “without special effort” in the Cures Act.  Will its proposal, if implemented, unfairly advantage some market participants?  Many digital health innovators view API-driven data interoperability as a necessary predicate to building two-sided marketplaces.  What happens when a large technology giant can forego API fees to gain marketshare?  Should the ONC determine the winners of API-driven interoperability before the market has had a chance to mature?
Related Posts
Back To Top