Proposals from the CMS to Reduce Burden

Since the past couple of years, the CMS began its journey to instill interoperability into the healthcare ecosystem and trying to bring about a culture of patient-centricity into the picture. The Interoperability and Patient Access final rule aimed to address the existing drawbacks hampering interoperability and thereby improve the quality of care. However, it missed out on addressing certain loopholes which were later pointed out by the stakeholders from within the healthcare ecosystem.
In the previous blog, we’ve seen the shortcomings of IPA, as well as the challenges that lie within prior authorization.
Let’s take a closer look at the proposals put forth by the CMS to reduce provider and patient burden.

Patient Access API  

Through the span of a patient’s life, they receive care from multiple providers, and their health records are mismanaged and separated into siloed data systems. Patients are unable to gain access to a comprehensive health care record of their own, resulting in the wrong care decisions. The following proposals are to help patients make informed care decisions.

  • Implementation Guides (IG) of the Patient Access APIs are no longer optional, as they were in IPA final rule, but mandatory to improve interoperability and data exchange.
  • Pending and active prior authorization details to be made public via the patient access API.
  • Attestation from third-party app developers, who retrieve data via the Patient Access API, to ensure adherence to specific privacy provisions.

Provider Directory API 

Thanks to the introduction of the provider directory API, patients can now access details regarding care and treatment from third-party applications. Providers can also use this functionality to track down other care providers for care collaboration purposes, if and when the need arises. However, for the lack of any mandated standardization, the API did not fulfill interoperability requirements.

  • The implementation guides recommended in the Interoperability and Patient Access final rule are to be made mandatory. To that effect, the latest proposals require the provider directory API to be conformant with the HL7 FHIR Da Vinci PDex Plan Net.

Provider Access API 

As of now, there is no provision available for providers to directly access patient information. At the point of care, they are clueless when it comes to the prior authorization details and the patient’s health history. To have access, they must request the information from the payers. These proposals would make sure that providers have immediate access to patient details at the point of care, reducing administrative burden, for both providers and payers, and ensuring quick and informed care delivery.

  • Payers must build and maintain a Provider Access API that makes patient data available to providers who are within a contract or not, on request.
  • Mandatory utilization of IGs while developing the Provider Access API.
  • Employ HL7 FHIR Bulk Data Access (Flat FHIR) specification to facilitate the exchange of data for more than one patient at a time.

Documentation and Prior-Authorization Burden Reduction Through API  

Owing to the difference in policies offered by the payers, workflow structure in hospitals, different systems storing and processing data, prior authorization, etc. is a source of administrative burden and major burnout. The time spent aligning the prior authorization requests and responding to them eats up valuable time, which could result in delayed care. Payers are proposed to implement the APIs mentioned below to ensure effective data exchange.

  • Document Requirement Lookup Service (DRLS) API: Build and maintain an FHIR-enabled DRLS API, integrated with a provider’s EHR, from which they can electronically locate prior authorization requirements from each payer.
  • Prior Authorization Support (PAS) API: Implement an API conformant with the HL7 FHIR Da Vinci PAS), that facilitates prior authorization request and response, for items or services.

Adoption of Health IT Standards and Implementation Specifications  

Through the latest proposal, the CMS has required payers to adhere to certain health IT standards and specifications when it comes to implementing API or exchanging data. It is to help reduce administrative burden and that aids in decision-making that would result in an effective marketplace with quality health outcomes. The ONC, on behalf of the HHS, is proposing the specifications:

  • to support a nationwide health information technology infrastructure,
  • to support the federal alignment of standards for interoperability, and
  • to help patients and providers control the data being shared with stakeholders via APIs.

What can we do?

To ensure compliance with the above proposals which are soon to be rules – systems and processes within payer organizations must be re-examined. APIs must be conformant with the proposals and data must be kept secure and private throughout the exchanges via these APIs.

Nalashaa is equipped with both teams and knowledge to align your systems and workflows to the latest regulations, helping your healthcare organization stay compliant.

 Connect with us at, and let us discuss how we can help you reduce the burden of your payers and associated providers to improve the quality of care delivered to your members.

The following two tabs change content below.
Shireen Noushad

Shireen Noushad

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.

Leave a Reply

Your email address will not be published. Required fields are marked *