TheFhirStorm

What the information blocking rule requires of EHR APIs

Integration ops · · Abhinav Srivastava

You ask an EHR vendor for API access on behalf of a practice that uses their product. The vendor says no, or says yes with a fee and a six-month queue. Before you accept either answer, read the two rules that define what a certified vendor must offer. This post walks through the statute, the API certification criterion, the API conditions of certification and the exceptions an engineer meets in practice, with links to the regulation text.

The statute

The 21st Century Cures Act added conditions of certification to the Public Health Service Act. At 42 U.S.C. 300jj-11(c)(5)(D)(iv), a developer of certified health IT must have published application programming interfaces. It must allow health information to be accessed, exchanged and used without special effort through those interfaces. That includes access to all data elements of a patient's electronic health record, to the extent permitted by privacy law.

The same Act created the information blocking provision at 42 U.S.C. 300jj-52. For developers of certified health IT, health information networks and exchanges, a civil monetary penalty may not exceed $1,000,000 per violation.

Who is an actor

The regulation at 45 CFR Part 171 defines an actor in 171.102 as a health care provider, a health IT developer of certified health IT, a health information network or a health information exchange. An EHR or practice management vendor with a certified module is an actor. A startup that builds on the vendor's API is not an actor unless it fits one of those four roles.

171.103 defines information blocking as a practice that, except as required by law or covered by an exception, is likely to interfere with access, exchange or use of electronic health information. For a developer, the standard is that it knows or should know the practice is likely to interfere. For a provider, the standard is that it knows the practice is unreasonable and likely to interfere.

Electronic health information is defined in 171.102 as electronic protected health information to the extent it would be in a designated record set, excluding psychotherapy notes and information compiled for legal proceedings.

The standardized API criterion

The certification criterion for the API itself is 45 CFR 170.315(g)(10), Standardized API for patient and population services. It requires a certified module to:

  • Respond to requests for a single patient's data and for multiple patients' data as a group, using the adopted FHIR standard and the US Core implementation guide, with all mandatory and must-support elements.
  • Respond to search requests consistent with the US Core server capability statement.
  • Enable an application to register with the module's authorization server.
  • Establish a secure connection for patient, user and system scopes.
  • Issue a refresh token valid for no less than three months to confidential applications, and grant access on later connections without re-authorization when a valid refresh token is supplied.
  • Revoke an application's access at a patient's direction within 1 hour.
  • Receive and validate tokens it has issued.
  • Publish documentation of the API syntax, parameters, return types, exceptions and registration requirements through a publicly accessible hyperlink without any preconditions or additional steps.

ONC's certification companion guide names the versions: FHIR 4.0.1, US Core STU 6.1.0, SMART App Launch 2.0.0 and Bulk Data Access 1.0.0. It states that registration is not a form of review or vetting for the criterion.

The API conditions of certification

45 CFR 170.404 adds business conditions on top of the technical criterion. A certified API developer must publish complete business and technical documentation, including all fees, at a public link. Fees to an API user are permitted only for value-added services that are not necessary to develop and deploy production software. The developer may not condition the right to use the certified API on a license fee, royalty or revenue share, or on reciprocal access to the application's data.

The timing rules matter for an integration plan. Under 170.404(b)(1), a developer may verify the authenticity of an API user, but the process must be objective, the same for all users and complete within ten business days. The developer must then register and enable the application for production within five business days. Under 170.404(b)(2), the developer must publish, at no charge, the service base URLs for all its customers in FHIR Endpoint and Organization resource format, reviewed quarterly.

The exceptions

A practice that meets an exception is not information blocking. The current text of Part 171 lists these exceptions: preventing harm (171.201), privacy (171.202), security (171.203), infeasibility (171.204), health IT performance (171.205), protecting care access (171.206), manner (171.301), fees (171.302), licensing (171.303) and TEFCA manner (171.403). ONC's information blocking page notes that a practice which meets no exception is not automatically information blocking; it is evaluated case by case.

Two exceptions come up in API negotiations.

Infeasibility

171.204 permits an actor to decline a request when one of five conditions holds:

  • An uncontrollable event, such as a disaster or an internet service interruption.
  • The actor cannot segment the requested information from information that must be withheld.
  • A third party asks to modify EHI, unless the requester is a provider and the actor is its business associate.
  • The manner exception was exhausted.
  • The request is infeasible under the circumstances, shown by a contemporaneous written record of the cost, the actor's resources and whether the actor gives the same access to its own partners.

In every case the actor must give the requester the reasons in writing within ten business days.

Manner

171.301 was titled the Content and Manner exception before the amendment at 89 FR 1437 on January 9, 2024, and the current text is titled the Manner exception. An actor must fulfill a request in any manner requested, unless it is technically unable or cannot reach agreeable terms. If it cannot, it must fulfill the request in an alternative manner, in order of priority: technology certified under Part 170 that the requester specifies; content and transport standards the requester specifies that are published by the Federal Government or an ANSI-accredited standards body; or an alternative machine-readable format agreed with the requester. When the actor uses an alternative manner, its fees must satisfy 171.302 and any license must satisfy 171.303.

What this means for a request

Ask for the certified API first, by name, with the criterion number. Point to the public documentation the vendor must publish under 170.315(g)(10)(viii)(B). Expect registration within the 170.404(b)(1) windows. If the vendor offers a different path, ask which exception it relies on and ask for the written reasons that 171.204(b) requires. Keep the exchange in writing.

All posts