IB the API, I think not

In a recent blog post, Assistant Secretary for Technology Policy Micky Tripathi described our agency's growing concerns about potential lack of compliance with statutes and regulations related to information sharing. That blog post covered issues related to developers of certified health IT and ASTP/ONC Health IT Certification Program (Certification Program) API requirements. In this blog post we share concerns that have been brought to our attention pertaining to potential violations of the information blocking regulations by health care providers as well as developers of certified health IT.

Practices by Health Care Providers

ONC has received over one information blocking complaint each business day since the regulation went into effect in April 2021, and almost 90% of these complaints have been against health care providers. During listening sessions we've conducted, we've heard concerns about many kinds of practices conducted by health care providers. One concern raised was that health care providers may be imposing pre-conditions on the access, exchange, and use of electronic health information (EHI) that are not required by the HIPAA Privacy Rule or the law of any jurisdiction in which they operate. For example, providers have been demanding HIPAA Business Associate Agreements (BAAs) when HIPAA would not require them, such as for an app facilitating an individual's access to their own EHI. Other concerns involved perceived barriers to access such as gatekeeping, delays, and difficulties in establishing the connection or registration of apps used by patients to access their EHI. Not only do the information blocking regulations cover these examples and similar types of practices, but we also specifically addressed certain situations in rulemakings and FAQs, noting that the practices would or, would likely, implicate the information blocking regulations. The following are some of these practices:

• A health care provider who has locally hosted EHR technology certified to  170.315(g)(10) chooses not to automatically publish its service base URLs, but instead only to provide them to specifically approved apps, preventing applications (and therefore patients) from accessing data that should be readily accessible via standardized APIs (84 FR 7518).
• A health care provider who locally manages their FHIR servers without a Certified API Developer's assistance refuses to provide to a Certified API Developer the FHIR service base URL(s) necessary for patients to access their EHI (85 FR 25813).
• A health care provider chooses not to enable the capability for patients to directly transmit or request for direct transmission of their EHI to a third party, when their EHR developer's patient portal offers this capability (84 FR 7519).
• A health care provider has the capability to provide same-day access to EHI in a form and format requested by a patient or a patient's health care provider, but takes several days to respond (84 FR 7519). We also noted that it would likely be an interference where a delay occurs in providing a patient's EHI via an API to an app that the patient has authorized to receive their EHI (FAQ22.1.2021MAR and 89 FR 63802).
• A health care provider states that the certified API is solely available for patient access and not for access by other authorized parties such as other providers.

Practices by Developers of Certified Health IT

Interested parties have also raised specific concerns regarding API-related practices by developers of certified health IT. Some concerns described developers' failures to publish service base URLs for patients' access to their EHI (45 CFR 170.404(b)(2)), and developers' willingness to provide the URLs only to specifically approved apps. Other concerns described developers' refusals to register and enable apps for production use within the required time (45 CFR 170.404(b)(1)(ii)), after authenticity verification had been completed.

We described these practices and similar types of practices in the Cures Act Final Rule, where we stated that the public availability of service base URLs in support of patient access is an absolute necessity, without which the access, exchange, and use of EHI would be prevented (85 FR 25813). As we've stated, any actions by an actor to restrict the public availability of such URLs would not only likely constitute an interference under the information blocking regulations, but would prevent access, exchange, and use of EHI altogether (85 FR 25813). Similarly, we've stated that an actor's refusal to register an app that enables a patient to access their EHI would also effectively prevent its use, rendering it unable to connect to certified API technology (85 FR 25813). We noted that such refusals in the context of patient access would be highly suspect, and likely to implicate information blocking (85 FR 25813).

In addition, we also pointed to other examples in the Cures Act Final Rule of practices by developers of certified health IT that could implicate information blocking, such as:

• A refusal to license or grant the rights necessary to distribute applications that use an API's interoperability elements, or a refusal to provide the services that are necessary to enable such applications to be used in production environments (84 FR 7519).
• A requirement that for an app to be listed on the developer's platform, the app developer must grant the developer of certified health IT the right to the app's source code or other intellectual property (84 FR 7520).
• A developer of certified health IT charging app developers a substantial fee to list their apps on the developer's platform unless an app developer agrees not to deploy the app in any other EHR developers' "app stores." (84 FR 7520).

In light of the feedback we have received through our listening sessions and complaints, we strongly encourage all information blocking actors and specifically health IT developers of certified health IT to review the examples of practices that could implicate the information blocking regulations.

Developers who participate in the Certification Program have both initial and ongoing obligations as part of their compliance with the Conditions and Maintenance of Certification requirements. One of those is the Information Blocking Condition of Certification, under which a developer may not take any actions that constitute "information blocking" as defined in 45 CFR 171.103. As part of the Assurances Condition of Certification, a developer must also provide assurances that it will not take any action that constitutes information blocking, or any other action that may inhibit the appropriate access, exchange, or use of EHI.

It's important to remember that the information blocking Condition of Certification (45 CFR 170.401) requires that a health IT developer participating in the Certification Program ensure that all of its health IT and related actions and behaviors do not constitute information blocking or inhibit the appropriate access, exchange, and use of EHI (85 FR 25718). As information blocking actors, Certified API Developers that engage in any practice they should know is likely to interfere with the access, exchange, or use of EHI may be committing information blocking (unless the practice is required by law or covered by an exception).

It's also important to bear in mind that health IT developers of certified health IT can implicate the information blocking condition (45 CFR 170.401) and definition (45 CFR 171.103) through non-conformity with other Certification Program requirements, such as API-specific conditions (45 CFR 170.404) or the Assurances requirement to not interfere with a user's ability to access or use certified capabilities (45 CFR 170.402(a)(3)).

For additional information, see our existing resources such as examples we gave of actors' actions that would likely constitute information blocking in the context of the Certification Program, our Certification Program page, our fact sheet on information blocking reminders related to API technology, and proposals in the HTI-2 Proposed Rule.

Moving Ahead

The concerns raised in our previous blog post and this one are a caution and an opportunity. They are a caution for all information blocking actors, including health care providers and health IT developers of certified health IT, to carefully review their practices and the information blocking regulations. They are also an opportunity to evaluate one's practices, policies, and procedures to ensure that health information flows where and when it is needed. As noted in our previous blog post, ASTP will continue to engage with our partners at OIG to carefully monitor areas of regulatory concern related to information blocking and with the Certification Program.

Health care providers and developers of certified health IT are both "actors" under the information blocking regulations, and each must do their part to enable authorized parties and/or patients to access EHI. Delineation of culpability for information blocking will be a key aspect of any investigations and enforcement actions undertaken in this area.

Please continue to share your input through the Health IT Feedback and Inquiry Portal, subscribe to ASTP's email newsletter at the bottom of the page on healthit.gov, and check back here for upcoming news and events. Further, if you believe you have been the victim of information blocking or suspect information blocking is occurring, please submit a complaint through our Report Information Blocking Portal. By law, information we receive in connection with a claim or suggestion of possible information blocking that could identify who submitted the claim shall not be disclosed except as necessary to carry out the information blocking statute and is exempt from mandatory disclosure under the Freedom of Information Act (FOIA).

Public link

Please use the above public link if you want to share this noodl on another website.