New Fact Sheet Highlights ASTP’s Concerns About Certified API Practices

On October 29, 2024, the US Department of Health and Human Services (HHS) Assistant Secretary for Technology Policy (ASTP) released a fact sheet titled “Information Blocking Reminders Related to API Technology.” The fact sheet reminds developers of application programming interfaces (APIs) certified under the ASTP’s Health Information Technology (IT) Certification Program and their health care provider customers of practices that constitute information blocking under ASTP’s information blocking regulations and information blocking condition of certification applicable to certified health IT developers.

In Depth


The fact sheet is noteworthy because it follows ASTP’s recent blog post expressing concern about reports that certified API developers are potentially violating Certification Program requirements and engaging in information blocking. ASTP also recently strengthened its feedback channels by adding a section specifically for API-linked complaints and inquiries to the Health IT Feedback and Inquiry Portal. It appears increasingly likely that initial investigations and enforcement of the information blocking prohibition by the HHS Office of Inspector General will focus on practices that may interfere with access, exchange, or use of electronic health information (EHI) through certified API technology.

The fact sheet focuses on three categories of API-related practices that could be information blocking under ASTP’s information blocking regulations and Certification Program condition of certification:

  • ASTP cautions against practices that limit or restrict the interoperability of health IT. For example, the fact sheet states that health care providers who locally manage their fast healthcare interoperability resources (FHIR) servers without certified API developer assistance may engage in information blocking when they refuse to provide to certified API developers the FHIR service base URL necessary for patients to access their EHI.
  • ASTP states that impeding innovations and advancements in access, exchange, or use of EHI or health-IT-enabled care delivery may be information blocking. For example, the fact sheet indicates that a certified API developer may engage in information blocking by refusing to register and enable an application for production use within five business days of completing its verification of an API user’s authenticity as required by ASTP’s API maintenance of certification requirements.
  • ASTP states that burdensome or discouraging terms, delays, or influence over customers and users may be information blocking. For example, ASTP states that a certified electronic health record (EHR) developer may engage in information blocking by conditioning the disclosure of interoperability elements to third-party developers on the third-party developer entering into business associate agreements with all of the EHR developer’s covered entity customers, even if the work being done is not for the benefit of the customers and HIPAA does not require the business associate agreements.

The fact sheet does not address circumstances under which any of the above practices of certified API developers may meet an information blocking exception (established for reasonable practices that interfere with access, exchange, or use of EHI). Regulated actors should consider whether exceptions apply to individual circumstances.

Proposed Health Information Technology Strategy Aims to Promote Innovation

Sheppard Mullin 2012

On April 7, 2014, the Food and Drug Administration (FDA), in consultation with theOffice of the National Coordinator for Health Information Technology (ONC) and the Federal Communications Commission (FCC) released a draft report addressing a proposed strategy and recommendations on an “appropriate, risk-based regulatory framework pertaining to health information technology.”

This report, entitled “FDASIA Health IT Report: Proposed Strategy and Recommendations for a Risk-Based Framework”, was mandated by Section 618 of the Food and Drug Administration and Innovation Act, and establishes a proposed blueprint for the regulation of health IT.  The FDA, ONC and FCC (the Agencies) noted that risk and controls on such risk should focus on health IT functionality, and proposed a flexible system for categorizing health IT and evaluating the risks and need for regulation for each category.

The Agencies set out four key priority areas: (1) promote the use of quality management principles, (2) identify, develop, and adopt standards and best practices, (3) leverage conformity assessment tools, and (4) create an environment of learning and continual improvement.

The Agencies are seeking public comment on the specific principles, standards, practices, and tools that would be appropriate as part of this regulatory framework.  In addition, the Agencies propose establishing a new Health IT Safety Center that would allow reporting of health IT-related safety events that could then be disseminated to the health IT community.

The Agencies also divided health IT into three broad functionality-based groups: (1) administrative, (2) health management, and (3) medical device. The Agencies noted that health IT with administrative functionality, such as admissions, billing and claims processing, scheduling, and population health management pose limited or no risk to the patient, and as a result no additional oversight is proposed.

Health IT with health management functionality, such as health information and data exchange, data capture and encounter documentation, provider order entry, clinical decision support, and medication management, would be subject the regulatory framework proposed in the report.  In addition, the FDA stated that a product with health management functionality that meets the statutory definition of a medical device would not be subject to additional oversight by the FDA.

The report had a spotlight on clinical decision support (CDS), which provides health care providers and patients with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care.  The report concluded that, for the most part, CDS does not replace clinicians’ judgment, but rather assists clinicians in making timely, informed, higher quality decisions.  These functionalities are categorized as health management IT, and the report believes most CDS falls into this category.

However, certain CDS software – those that are medical devices and present higher risks – warrant the FDA’s continued focus and oversight.  Medical device CDS includes computer aided detection/diagnostic software, remote display or notification of real-time alarms from bedside monitors, radiation treatment planning, robotic surgical planning and control, and electrocardiography analytical software.

The FDA intends to focus its oversight on health IT with medical device functionality, such as described above with respect to medical device CDS.  The Agencies believe that this type of functionality poses the greatest risk to patient safety, and therefore would be the subject of FDA oversight.  The report recommends that the FDA provide greater clarity related to medical device regulation involving health IT, including: (1) the distinction between wellness and disease-related claims, (2) medical device accessories, (3) medical device CDS software, (4) medical device software modules, and (5) mobile medical apps.

The comment period remains open through July 7, 2014, and therefore the report’s recommendations may change based on comments received by the Agencies. In the meantime, companies in the clinical software and mobile medical apps industry should follow the final guidance recently published by the FDA with respect to regulation of their products.

In the meantime, health information technology companies should follow the final guidance recently published by the FDA with respect to regulation of their products.

Article By:

Of: