Best-in-class solution for the CMS Interoperability and Patient Access Final Rule
Firely helps Payers and Health Plans achieve full compliance with the CMS Interoperability Rule
The CMS Interoperability and Patient Access Final Rule
Lack of seamless data exchange in healthcare has historically detracted from patient care, leading to poor health outcomes, and higher costs.
The Interoperability and Patient Access final rule put patients first by giving them access to their health information when they need it most, and in a way they can best use it. The Rule was issued by the Centers for Medicare & Medicaid Services (CMS) in May 2020.
It focuses on promoting interoperability and patient access to health information for beneficiaries of Medicare Advantage, Medicaid, and the Children’s Health Insurance Program (CHIP). The rule requires health plans to share claims data, clinical data, and other types of health information with patients and other healthcare providers in a standardized, secure, and timely manner.
Promote the interoperability of health IT systems
The CMS Interoperability Rule aims to promote greater interoperability, patient access, and innovation in the healthcare industry, while also improving the quality and cost-effectiveness of care. This includes five important provisions.
Patient access to health information
The rule requires health plans to make patient health information available through APIs. Patients will be able to access their health information through mobile applications or other third-party tools.
Access to Prior Authorization
The rule focuses on efforts to improve prior authorization processes to help ensure that patients remain at the center of their own care and they get the health care that they need within minutes instead of days.
Exchange of health information
The rule requires health plans to exchange certain types of health information, such as claims data and encounter data, with other health plans and with patients through APIs.
Improve care coordination
The rule aims to improve care coordination among healthcare providers by making it easier to exchange patient health information securely and in a timely manner.
Reduce healthcare costs
The rule aims to reduce healthcare costs by promoting competition among healthcare providers and enabling patients to make more informed decisions about their healthcare.
Important interoperability policies
The CMS Interoperability Rule consists of several interoperability policies, including:
Patient Access API
The Patient Access API is a policy that requires Medicare Advantage, Medicaid, and CHIP plans to provide their beneficiaries with access to their claims and encounter data through a standards-based API. The API enables beneficiaries to access and share their health information with third-party applications of their choice.
Provider Access API
The Provider Access API requires payers to build and maintain a Provider Access API to share patient data with in-network providers with whom the patient has a treatment relationship. The Provider Access API allows third-party software applications to connect to and access data from an EHR system using FHIR standards.
Prior Authorization Requirements, Documentation, and Decision (PARDD) API
This policy requires Medicaid, CHIP, and certain types of private health plans to make their prior authorization processes electronic and to offer a standards-based API to providers and patients for submitting and receiving prior authorization requests and decisions.
Provider Directory API
The Provider Directory API is a policy that requires Medicare Advantage, Medicaid, and CHIP plans to make provider directory information available through a standards-based API. The API enables beneficiaries to find and select healthcare providers based on location, specialty, and other criteria.
Payer-to-Payer Data Exchange
The Payer-to-Payer Data Exchange policy requires Medicare Advantage, Medicaid, and CHIP plans to exchange certain types of health information, such as claims and encounter data, with other health plans upon beneficiary request. The policy aims to promote care coordination and continuity of care for beneficiaries who switch health plans.
Let’s discuss how Firely can help you to get ready!
The challenges for Medicare Advantage, Medicaid, and the Children’s Health Insurance Program (CHIP)
- Comply with CMS rule’s interoperability policies
Health plans must comply with the CMS rule’s interoperability policies within specific timeframes, which can be challenging given the technical and operational complexities involved. Failure to comply with the rule can result in penalties and other consequences. - Resources, high costs and the lack of knowledge
Implementing the interoperability policies in the CMS rule requires the use of advanced health IT systems and data standards. They also require significant financial resources and staff time, which may pose a challenge for smaller healthcare providers and organizations. - Coordination and collaboration
Implementing the CMS rule’s interoperability policies requires coordination and collaboration between health plans, healthcare providers, and patients. Health plans must engage with these stakeholders to ensure that the policies are implemented effectively and that the benefits of greater interoperability are realized.
Discover the best in class solution in the market
Built by one of the initiators of FHIR, Firely Server is a FHIR-native plug-and-play solution, that is loosely coupled and fully integrated with your product. It’s fully compliant with the CMS Interoperability and Patient Access Final Rule. Expanding the CMS Interoperability and Patient Access Final Rule means that our roadmap is constantly kept up to date with the latest regulations and recommended IGs.
Firely Server
ONC compliant FHIR server
Firely Server is our turn-key FHIR server created by one of the initiators of FHIR.
It contains all the features you need to be fully CMS compliant.
Firely Auth
Firely Auth is the authentication server that is seemlessly integrated with SMART on FHIR. Firely Auth is specifically configured to speak FHIR.
Bulk data export
With this plugin you can export bulk data in two ways: an asynchronous data export based on the FHIR Bulk Data Access (or “Flat FHIR”) Implementation Guide, or by using the Patient $everything Operation.
SMART on FHIR
This plugin enables authentication based on the SMART on FHIR specification and allows you to integrate Firely Server with your own authentication and authorization system.
Audit Logging
Firely Server can log access through the RESTful API for auditing purposes.
Firely is certified under the Office of the National Coordinator for Health Information Technology’s (ONC) Health IT Certification Program. For more information go to the Mandatory Disclosures and API Documentation on our website.
Some interesting reads
Evaluating Firely Server is quick and easy. Here are the two best ways to check it out.
You’ll obviously want to check out Firely Server before you make a purchase. There are two main ways to do just that, but it’s not always obvious which one to choose. That’s something we wanted to clarify, so this article explains how to evaluate Firely Server – with or without a download.
IGs & Technical Documentation
With our Firely Server solution, we support multiple IGs (s.a. SMART, Bulk Data Access, CARIN, Da Vinci, USCDI & US Core). In our Technical Documentation you can find all of the FHIR Implementation Guides that have been verified by Firely to work out-of-the-box with Firely Server.
How to Build a Dynamic FHIR Implementation Guide
The Simplifier Implementation Guide Editor is the intuitive user interface where you can quickly start creating FHIR Implementation Guides. In recent releases of Simplifier.net we introduced the Firely Query Language (FQL), for dynamic tables of information from your resources, and the feature to create copies of your FHIR Implementation Guides (IG).
Your partner for the CMS Interoperability and Patient Access Rule
Find out how we can help you achieve compliance.
Leave a message and we’ll get back to you within 24 hours.