Common API Implementation Issues
Despite the strong foundation laid by certification requirements, many Certified API Developers continue to face real-world challenges that limit the effectiveness and usability of their APIs. The following sections examine some of the most persistent implementation issues, starting with documentation access and URL publishing, and provide guidance to help developers bring their practices in line with program expectations.
Accessing API Documentation and URL Issues
Common problems include unresolvable hyperlinks, links that do not direct users to actual API documentation, and service base URL directories that fail to list customer-specific endpoints. In some cases, links redirect to developer homepages, requiring users to navigate additional content and obstructing automation. Other instances involve the absence of published patient access API service base URLs or the omission of healthcare organization details within those listings.
In accordance with program requirements, Certified API Developers must keep their API documentation links current, publish and maintain accurate service base URLs for all customers, and ensure that both service base URLs and associated organizational information are made available in the FHIR bundle format as specified under 45 CFR 170.404(b)(2).
API Technical Documentation Issues
Common issues include lack of sufficient public-facing information to support a streamlined registration process, as well as the absence of support contact information, limited or outdated API documentation, and no defined channels for app developers to provide feedback on the registration process or technical documentation. These deficiencies create barriers to effective integration and may lead to confusion or delays.
Under program requirements, Certified API Developers must publish and maintain complete, up-to-date business and technical documentation. This includes all necessary information for registering an application in a production environment, such as terms of use and detailed registration process requirements.
API Registration Challenges
In some implementations, third-party application developers are required to go through individual registration and approval processes for each health system or provider organization. This often includes filling out separate, manual questionnaires for each service base URL or FHIR endpoint, significantly increasing the administrative burden. In many cases, these registrations are not completed in a timely manner, resulting in delays that hinder both interoperability and patient access to data.
Under the API Maintenance of Certification requirements, Certified API Developers are obligated to register applications for production use with their § 170.315(g)(10)-certified Health IT Module. These requirements include specific timelines for processing registration requests. If a developer chooses to verify the authenticity of API Users, the verification process must be objective, applied consistently across all users, and completed within ten business days of receiving the request. Once verified, registration for production use must be completed within five business days.
In addition to delays in developer registration, some implementations impose non-standard authorization processes on patients who wish to connect third-party applications. These include requiring patients to use out-of-band methods or to initiate app connection requests through their healthcare providers. In some cases, patients must even create entirely new login credentials with the data holder, rather than using their existing patient portal credentials. These added steps create unnecessary barriers and reduce the usability of patient-facing health apps.
To meet certification expectations, Certified API Developers must ensure their APIs are implemented in a way that allows electronic health information to be accessed, exchanged, and used without special effort. Health IT Modules certified under § 170.315(g)(10) must support application registration with the module’s authorization server and enable standardized authentication and authorization according to the SMART App Launch Framework.
Finally, Certified API Developers are prohibited from introducing additional requirements that block or delay app registration. For example, requiring third-party developers to sign a HIPAA Business Associate Agreement or enter into a business partnership before granting production access to patient data is not allowed. Program guidance makes clear that Certified API Developers cannot make HIPAA BAAs, business relationships, or similar contractual agreements a condition for registering apps that enable patient access to electronic health information through certified API technology.
Misuse of Value-Added Services
Certain implementations have raised concerns regarding the use of “consumer education” practices that function more as deterrents than as informative tools. These often take the form of warning messages that appear during the app connection process, which may discourage patients from linking third-party applications to their health data.
In some cases, third-party app developers are given the option to pay a fee in order to be designated as a “known” app, thereby allowing these warning messages to be removed for their users. While Certified API Developers are permitted to charge fees for value-added services related to certified API technology (including those that have a reasonable profit margin) these services must be supplemental. They cannot be required for the efficient and effective development, testing, or deployment of production-ready software applications that interact with certified API technology. Furthermore, any fees that do not align with the provisions set forth under 45 CFR 170.404(a)(3) are strictly prohibited.
App authorization – interference vs education
Certified API Developers must ensure that their efforts to educate patients about the privacy and security practices of third-party applications do not constitute information blocking. For example, displaying a notification during the app authorization process that evaluates whether an app developer’s privacy policy meets certain “best practices” set by the market may inadvertently discourage patient access and raise compliance concerns.
To avoid information blocking, any educational content provided must focus on clearly identifying current privacy or security risks posed by the application. The information must also be factually accurate, unbiased, objective, and communicated in a non-discriminatory manner, without being unfair or deceptive.
These requirements help ensure patients can make informed decisions without being unduly influenced or discouraged from connecting apps of their choice.
App authorization – ease of use features
Some certified API technologies present usability challenges within the FHIR scope authorization interface, particularly for patients attempting to authorize multiple scopes during the app connection process. For instance, when no scopes are pre-selected by default, patients who wish to approve all requested scopes must manually select each one individually. This can result in a cumbersome and inefficient user experience.
To improve accessibility and usability, it is recommended that certified API technology include interface options such as “select all” and “de-select all” within the scope authorization interface. These features can help ensure a more streamlined and user-friendly process for patients managing their data access preferences.
Developer Testing Environment (“Sandboxes”)
At times, developers provide limited access to development sandboxes and synthetic health information, which restricts app developers’ ability to test their applications before interacting with a live production environment. For example, an app developer may seek to validate that their application functions correctly with certified API technology, but the lack of a dedicated test environment can impede this process.
To support effective development and integration, it is recommended that certified API technology include access to a developer sandbox and synthetic data. These resources enable app developers to conduct testing in a safe, controlled environment prior to engaging with real-world deployments.
API Condition of Certification: Overview
As part of understanding the expectations tied to the API Condition of Certification, it is essential to review the key components that shape how Certified API Developers must design, deliver, and support their certified API technology. The following areas outline the regulatory framework established to ensure transparency, fairness, and accessibility in the health IT ecosystem.
Transparency Condition
Certified API Developers are required to publish comprehensive business and technical documentation that clearly outlines how third parties can interact with their certified API technology. This includes detailed explanations of integration procedures, system requirements, terms of use, and any other relevant operational information.
Additionally, all fees associated with the use of the certified API technology must be described in plain language, ensuring that the cost structure is transparent and easily understood. Importantly, all required documentation must be made available through a publicly accessible hyperlink, enabling any individual to directly access the information without encountering login requirements, gated content, or additional steps. This level of transparency is essential to supporting interoperability, fostering trust, and promoting a fair and open health IT environment.
Fees Condition
Certified API Developers are permitted to charge certain fees in connection with their certified API technology, provided those fees comply with program requirements. Specifically, developers may charge API Information Sources, such as health systems or data holders, for the development, deployment, and upgrade of their certified API technology.
Additionally, they may recover costs related to API usage from these sources, if applicable. Certified API Developers may also charge API Users, such as third-party application developers, for optional value-added services. However, these services must be supplemental and cannot be essential to the efficient and effective development, testing, or deployment of production-ready software. This framework is designed to ensure that fee structures support sustainability without creating barriers to innovation or access.
Openness and Pro-Competitive Condition
To promote an open and competitive marketplace, Certified API Developers must meet several key requirements. First, they are obligated to grant API Information Sources the independent authority to allow API Users—such as third-party application developers—to interact with the certified API technology deployed by the Information Source. Certified API Developers must also ensure that all terms and conditions related to their certified API technology are non-discriminatory. This includes providing both API Information Sources and API Users with the necessary rights to access and use the technology without unfair restrictions. Furthermore, developers must avoid prohibited conduct that could hinder competition or limit access.
Finally, they are required to meet specific service and support obligations to facilitate the effective and practical use of certified API technology by all authorized parties. These measures collectively reinforce fairness, transparency, and interoperability across the health IT ecosystem.
API Maintenance of Certification
In addition to the initial certification criteria, Certified API Developers are also subject to ongoing responsibilities to maintain compliance over time. These are known as the API maintenance of certification requirements. One such obligation allows developers to implement an authenticity verification process for API Users, provided the process is objective, applied consistently to all users, and completed within ten business days of receiving the registration request. Following this, the application registration process must be completed within five business days, enabling the verified application for production use without unnecessary delay.
In addition, developers must ensure the publication of service base URLs for all customers utilizing certified API technology. These URLs must support patient access to their electronic health information and must be made publicly available to promote accessibility, transparency, and compliance with federal program requirements.
Current Service Base URL Publication Requirements
The maintenance of certification requirement at § 170.404(b)(2) mandates that Certified API Developers must publish, at no charge, the service base URLs (also referred to as FHIR endpoints) for all Health IT Modules certified to § 170.315(g)(10).
These endpoints must be accessible to support patient access to their electronic health information. Each service base URL must be published using the FHIR Endpoint resource format, and it must be accompanied by corresponding organization details, including name, location, and facility identifier, using the FHIR Organization resource format. These resources must then be aggregated and published in a FHIR Bundle resource format.
Compliance with Program Requirements: Conditions and Maintenance of Certification
A significant concern within the health IT community is the potential for Certified API Developers to fall out of compliance with the API Conditions and Maintenance of Certification requirements outlined in 45 CFR 170.404, as well as the information blocking provisions under 45 CFR 170.401. Failure to meet these obligations can jeopardize a developer’s continued participation in the Certification Program and negatively affect the broader health IT ecosystem. Noncompliance undermines trust in health IT by reducing confidence in the reliability and integrity of certified technologies. It also hampers technology adoption, as inconsistent API performance or limited availability discourages users from engaging with new tools and services.
This hesitation slows innovation and directly impacts the success of health IT products. Moreover, addressing compliance gaps introduces inefficiencies and elevates operational costs, both for developers and their users. Most critically, unreliable APIs can delay access to essential health data, adversely affecting patient care. Timely and accurate information is vital for clinical decision-making, and poor API performance can have real-world consequences. Compliance should not be viewed as a one-time requirement but as a foundational element that supports product viability, healthcare system efficiency, and improved patient outcomes.
Compliance with Program requirements: Information Blocking
Failure to comply with the API Conditions and Maintenance of Certification requirements under 45 CFR 170.404 may also serve as an indicator of potential violations of the information blocking regulations outlined in 45 CFR 170.401. Certified API Developers are considered actors under the information blocking rule at 45 CFR part 171 and may be found to be engaging in information blocking if they knowingly, or should reasonably know, that their actions, or failure to act, are likely to interfere with the access, exchange, or use of electronic health information (EHI), unless such practices are required by law or fall within a recognized exception.
Addressing these issues is a collaborative effort involving the U.S. Department of Health and Human Services (HHS) Office of Inspector General (OIG) and the Centers for Medicare & Medicaid Services (CMS). The OIG is actively positioned to investigate credible allegations of information blocking, and developers, health information networks, or health information exchanges found in violation may be subject to civil monetary penalties of up to $1 million per infraction. In the case of healthcare providers, OIG refers substantiated cases to CMS, which then determines and applies appropriate disincentives based on the nature and impact of the provider’s actions.
This regulatory framework underscores the importance of maintaining compliance, not only to uphold certification but also to avoid serious legal and financial consequences.
Compliance with Program requirements: Surveillance and Enforcement
When significant concerns arise, ASTP (Assistant Secretary for Technology Policy) may initiate enforcement actions, which can include a direct review of certified health IT products and their developers. These reviews may result in corrective actions, and in more serious cases, the suspension or termination of a product’s certification status. In situations involving particularly severe or repeated non-conformities, a developer may even face removal from the Certification Program entirely. This enforcement process is a critical safeguard to ensure the trustworthiness and accountability of certified health IT solutions across the industry.
Key Takeaways
The collective feedback from stakeholders and the clarifications provided by ONC highlight a fundamental expectation: certified API technology must support not only technical compliance, but also a consistent and accessible implementation experience. The certification framework is intended to promote transparency, usability, and fairness across the health IT ecosystem. When documentation is clear, workflows are predictable, and integration pathways are unobstructed, certified APIs are better positioned to fulfill their intended role in advancing interoperability and supporting patient access to health information. This alignment between regulatory intent and real-world implementation is essential to sustaining confidence in certified technologies and achieving long-term program goals.