The deadline for getting a g(10) FHIR-based API in place is December 31, 2022. It is no longer knocking on the door, in fact, it is inside the living room. It might sound like every other healthcare certification. But g(10) is only a tiny piece of the multi-dimensional certification required for EHRs and providers.
Certification is not an easy task. You will have to go through a complex four-stage process after which you will able to produce FHIR-based g(10) features. Along with that, there is a set of important pointers that you must remember before implementation. Let’s first check out some of the myths related to the Cures Act and the checklist that every provider and EHR vendor must remember.
Some myths related to Cures Act that affect FHIR Implementation
- Deadlines will get extended: Many people are hopeful that ONC will extend the g(10) FHIR-based API requirement’s deadline past December 31, 2022. But that is not going to happen. It has been 11 years since ONC and HHS initiated these rules and almost 34.7 billion dollars was spent on paid incentives. This is why from the coming year the 21st Century Cures Act’s two-pronged enforcement requirements will strictly be carried out by the ONC and HHS. The mandatory certification updates for EHRs will be covered by ONC, and HHS will take care of any claims for information blocking made against possible actors (EHRs and Providers).
- The developer portal is optional: Every EHR is required to have a developer portal which will help in the approval of third-party apps that want to connect with the EHR’s API. EHRs can be integrated with Cures Act Certified Solutions to develop these portals.
- One-time effort: This is no longer going to be a one-time effort. A checkmark on your CHPL site will not satisfy all your requirements, therefore avoid using straightforward stand-alone solutions that merely let you “check the box” for g(10) compliance. You will need to continue having complete compliance with Real-World Testing, version updates every year and submitting biannual reports. Failing to do these by the deadline will result in decertification.
- USCDI V1 compliance will solve every compliance issue: No, it won’t. You will have to be compliant with both the USCDI V1 and V2. Additionally, the revised version of the information blocking rule states that providers must now be equipped to provide patients with every data of the ePHI included in the DRS.
Checklist to remember before implementing FHIR API
- Version compatibility: One of the most important things to check when evaluating an FHIR API is that it is compatible with the version of FHIR you are using. This ensures that any APIs you build will work correctly and won’t fail due to compatibility issues.
- Security: Another key factor to consider when checking an FHIR API is security. Ensure that all data stored in the API and all connections are secured, including authentication and authorization protocols such as OAuth 2.0 and OpenID Connect. To prevent unauthorized access, the API should also be equipped with appropriate defenses such as rate limiting and input validation checks.
- Reliability: The reliability of an API is paramount for successful implementation. To ensure this, check if the underlying platform hosting your service has high availability, redundancy, scalability, etc., and evaluate its uptime record in order to determine how reliable it is likely to be over time. It’s also important to test the performance of your application under peak loads to identify any potential bottlenecks or areas you can optimize performance-wise.
- Documentation: A comprehensive set of documentation should be provided by your FHIR API provider so developers can easily get started with using it right away without having to figure out complex technical details themselves first-hand trial-and-error style. Check if there are examples available for common tasks along with code samples for rapid integration; these will help speed up development significantly for any project leveraging an FHIR-based solution stack.
- Interoperability: Assess how well the FHIR API interacts with other services or systems both within your organization (e.g., data warehouses) and beyond (e.g., cloud computing providers). Make sure that different versions of FHIR are supported as well as non-FHIR systems/standards via integration protocols like OAuth2.0 or RESTful APIs.
- Compatibility & Portability: Verify support for deploying an FHIR API on various platforms (desktop/mobile), along with compatibility across a range of operating systems (Windows/Linux/macOS). Additionally, ensure compatibility exists across web browsers so users can access information from any device without experiencing any errors or malfunctions due to system incompatibility issues.
- Support: Last but not least, the availability of support from your provider when needed plays a major role in ensuring a successful implementation of an FHIR API into your production workflow or solution architecture; depending on their SLA terms they may provide different levels of customer support ranging from basic support through advanced technical assistance services as well as training options or managed services packages which might be helpful depending on your specific use case requirements and team size/structure etc.
How we can help?
We have been helping healthcare organizations all over the US for more than a decade now. Our experts will provide you with:
- Custom solutions
- Industry knowledge and support
- Interoperability utilizing verified FHIR APIs
We understand the importance of healthcare interoperability solutions in a provider’s journey toward value-based care.
Connect with us at info@nalashaa.com
The following two tabs change content below.
Mitrajit Das
A writer with a keen interest in the Healthcare domain and B2B content marketing. He enjoys writing and creating pieces around the latest Healthcare IT trends using the simplest of words.
Latest posts by Mitrajit Das (see all)
- HTI 1 Final Rule: Decoded for Healthcare Innovators - March 15, 2024