Reducing Operational Burden with FHIR APIs – Part 1
With the introduction of the Interoperability and Patient Access rule, FHIR APIs created quite the buzz within both the payer and the provider communities. As a follow-up to the rule, CMS released a couple of proposals urging payers to implement a few more FHIR-enabled APIs along with the implementation guides.
In this blog, let’s take a look at why these FHIR-enabled APIs were introduced in the first place, and how they’d help reduce the operational burden to whomsoever it may concern.
Patient Access API
Providers and payers take into account any medical conditions, allergies, past illnesses, prescribed drugs, etc. to deliver care that produces better care outcomes while being financially viable. Vital information such as the above is currently stored in disparate systems and time consuming for both payers and providers to retrieve it all.
Amidst all the systems and data formats, patients move from one provider to another in the span of their lifetime. Now, the new provider would need to access the patient’s previous health record and will have to get in touch with the payer to do so. This is where the FHIR-based Patient Access API comes in.
Through Patient Access API, payers are expected to share a list of data points with the third-party apps of a patient’s choice so that they can get their health information in a way that is most convenient and useful for them. This API would also allow patients to facilitate their data moving from their payer to their provider. A patient could use their mobile phone during a visit with their provider to share their data to help conduct their discussion.
Provider Directory API
Availing services from an out-of-network provider costs an arm and a leg and this has been a recurring issue within the healthcare ecosystem. This is owing to the fact that payers seldom have an updated list of the providers under their contract which is accessible by their members. To put an end to this and ensure affordable care is accessible, CMS has requested payers to make a provider directory accessible via a public-facing digital endpoint on the payer’s website to ensure public discovery and access.
Payers must make available the following via the Provider Directory API: provider names, addresses, phone numbers, and specialties. All directory information must be made available to current and prospective enrollees and the public through the Provider Directory API within 30 calendar days of a payer receiving provider directory information or an update to the provider directory information.
Provider Access API
As useful as Patient Access API is, CMS also decided that providers having access to the same patient data through an FHIR-based API that allows the provider to request data for a single patient as needed is beneficial. Provider access to patient information would improve both the provider and patient experience in the healthcare delivery cycle.
In the case of the Provider Access API, the provider would receive the data directly from the payer and incorporate it into their EHR or other practice management system. If providers could access information about the care their patient received outside of the provider’s care network prior to a patient’s visit, the information might improve clinical efficiency and provide a more comprehensive understanding of the patient’s health, thus potentially saving time during appointments and improving the quality of care delivered.
There are just a few of the FHIR-based APIs that payers need to implement in order to adhere to the latest and upcoming regulations. Read more on the rest of the FHIR-based APIs and their role in reducing burden in Part 2 of this series of blogs.
Let Us Help Reduce Your Burden
Keeping up the organizational workflows, enhancing them as and when required put a damper on the resources a payer has available to implement these new FHIR APIs. These APIs mentioned above are only the tip of the iceberg. Developers are to make themselves familiar with their implementation guides, ensure security protocols and attestations, take care of authorization and authentication among others while gearing up to implement these APIs.
Fret no more, we’ve got you covered. Nalashaa has experienced experts working with payers to enhance and build interoperability solutions. We are well aware of the workings of the ecosystem and have our ears to the ground, always up to arm you with updates the CMS throws your way. Connect with our experts at email@example.com and get your systems FHIRed up!
Latest posts by Shireen Noushad (see all)
- The Various Facets of FHIR - January 12, 2022
- Reducing Burden with FHIR APIs – Part 2 - December 31, 2021
- Reducing Operational Burden with FHIR APIs – Part 1 - December 30, 2021
- Posted In:
Currently, trying to navigate through the ocean of Healthcare IT systems, processes, and workflows. Passionate about writing, and stringing together words in the simplest of ways for a better reading experience and easier comprehension.All stories by: Shireen Noushad