By Avinash Shanbhag, ASTP/ONC
LinkedIn: Avinash Shanbhag
LinkedIn: ASTP
In recent posts “IB the API, I Think Not” and “Getting Real about Information Blocking and APIs” we discussed concerns about practices, actions, and behaviors that run counter to our policies promoting an open, standards-based approach to interoperability. Recent and ongoing reports received from “API Users,” which includes, among others, health care providers and app developers, indicate that certified health IT developers (in this context “Certified API developers”) have been engaging in activities that could be non-conformities under the ONC Health IT Certification Program (Certification Program).
In particular, we have received feedback that the registration process for third-party applications intended to be used by patients to access their electronic health information (EHI) is being obstructed by Certified API developers through delays, unnecessary requirements, and limited access to essential registration information. In this blog post we outline specific compliance areas associated with API registration that require developers’ attention to support an API user’s ability to utilize a third-party application to access EHI without special effort. Further clarification is provided in the API Certification Companion Guide (CCG) and the Information Blocking Reminders Related to API Technology Fact Sheet.
Delays and obstacles in third-party application verification and registration
Certified API developers are permitted to institute a process to verify the authenticity of API Users (e.g., third party apps). However, if they do so, they must complete their authenticity verification within ten business days of receipt of the API User’s request to register their software application for use with the “(g)(10)-certified API,” and must register and enable production use of verified apps within 5 business days thereafter.
Third-party app developers facilitating an API user’s access to EHI should not have to wait more than 15 business days for a Certified API developer to “approve” the app to be technically ready to support a patient seeking access to their EHI via that app. API Users have brought to our attention that in many cases, this process takes significantly longer. Such delays are unacceptable and represent potential non-compliance with Certification Program requirements. Certified API developers need to adhere to established timeliness standards and should bear in mind that these types of non-conformities are more easily identifiable given their quantifiable requirements.
API Users have also reported practices such as mandating additional agreements (e.g., business associate agreements or non-disclosure agreements), and the requirement that a patient or healthcare provider authorize the app before registering the app. These sorts of practices add unjustified barriers and are not allowed (see 85 FR 25813 and 84 FR 7520; see also HIPAA FAQ #5) at all for patient access, and not allowed if they unjustifiably impede business-to-business access.
Lack of accessible and transparent registration information
Reports of missing and inaccurate contact information, or unresponsive requests for third-party app registration on publicly accessible service base URLs indicate that some Certified API developers have not provided clear, accessible instructions, directly impeding the registration process. ASTP expects all information necessary to initiate and complete app registration to be consistently maintained, accessible, and easy to locate. Failure to comply with this expectation will likely implicate a violation of API and Information Blocking Conditions and Maintenance of Certification requirements.
Other barriers to API registration
Other concerns we’ve heard about include:
- Health care providers, which are considered API Information Sources under the Certification Program, discouraging the use of any third-party app registration, and directing patients to use their patient portals instead (84 FR 7519).
- Providers displaying biased, inaccurate and discriminatory messages designed to dissuade patients from using third party apps, under the guise of “consumer education.”(85 FR 7419)
- Refusal from some Certified API developers to publish the service base URL of their customers or providing generic API endpoints making it difficult for API Users to connect directly with the health systems.
Accountability and Enforcement
ASTP will continue to monitor compliance and address concerns in partnership with ONC-Authorized Certification Bodies (ONC-ACBs). As the Information Blocking regulatory and enforcement framework is now in place, it would be particularly wise for Certified API developers to take a moment to ensure their practices align with the API Conditions and Maintenance of certification requirements and streamline their registration process to ensure no “special effort” is introduced. To support this, the Certification Program has updated the CCG and released additional educational materials. We encourage Certified API developers to review this and all other educational materials available in our Certification Program resource page.
If you’re an app developer or other API User and encounter these or any other issues with a Certified API developer, we recommend you first contact the developer in question. This is the starting point for all complaints as indicated in the Certification Program’s complaint process. If the problem persists, consult the product’s ONC-ACB as listed on the ONC Certified Health IT Product List. Part of ONC-ACBs responsibilities include receiving complaints about the products they certify and to identify and address potential non-conformities to certified capabilities, including but not limited to 45 CFR 170.315(g)(10). As always, please continue to share your input through the Health IT Feedback and Inquiry Portal. Claims or questions related to non-compliance or practices inconsistent with the API Conditions and Maintenance of Certification requirements should be reported to the ASTP/ONC Health IT Feedback and Inquiry Portal.
This article was originally published on the Health IT Buzz and is syndicated here with permission.