When CMS issued Final Rule CMS-0057-F back in January, the prior authorization compliance requirements set to take effect in January of 2026 got most of the press attention. You can read our take here.

The rule has a second phase, though. Beginning January 1, 2027, CMS requires Medicare Advantage Plans (MAPs) and other federally funded payers to make certain data available via application programming interfaces, or APIs.

It doesn’t sound exciting, but it might be key to ultimately holding payers accountable and improving suppliers’ bottom lines.

Next Episode: Thursday, June 20, 2024

In layman’s terms …

CMS wants payers to create a Patient API so patients, suppliers, and even other payers can inexpensively access relevant health data …with patient permission, of course. The rule also mandates a Prior Authorization API to allow suppliers to:

  • Determine which items require prior authorization.
  • Determine the documentation required for a favorable authorization decision.
  • Request and receive authorizations.

CMS’s intent is almost certainly aimed at reducing hassles that beneficiaries run into when switching coverage among Medicare Fee-For-Service (FFS) and MAP options. Suppliers benefit nonetheless because API standardization will significantly reduce the number of costly manual processes currently needed to service patients, especially those switching insurance plans.

APIs require standardization. Standardization reduces costs.

At least for now, computers cannot exercise judgment. They require straight if/then logic. That means each transaction is processed with the same set of explicitly stated rules: if this happens, then do that. Given the same input, a computer program will return the same result every time. Better still, users – or other computer programs – can double check the answer because the rules are publicly available.

Contrast that to the way things work now. Given the same input, payers can give different answers, in wildly different formats, with no real explanation or support. Under these forthcoming rules, payers will have to force tedious application processes, mysterious decisions, and archaic response formats – the things that cost suppliers dearly – into a standardized structure required to implement the API.

APIs invite automation.

Any supplier that has ever checked Medicare eligibility by simply clicking a button inside their billing software has benefitted from an API. The software vendor, using an available API for Medicare’s eligibility database, created a piece of code that:

  • Gathers the patient information and eligibility parameters and sends it to the API.
  • Interprets the API’s response and translates it for the user.

With the API, users click the button. Without the API, users would need to:

  • Pick up the phone and call a Medicare customer service representative, or
  • Log into a website,
  • Manually enter the patient’s information, and
  • Update the billing software based on the results of the eligibility search query.

As CMS forces federally funded payers to establish APIs for patient health data and prior authorization transactions, software vendors will be able to convert more time-consuming steps into button clicks. That saves time. That saves money.

In closing …

CMS is clearly serious about ensuring MAPs and other federally funded payers are transparent in their dealings and compliant with its directives. APIs add a practical element that takes it to the next level by replacing ambiguity with strict logic that can be evaluated in real time with each transaction.

In my opinion, suppliers should advocate for APIs fervently; it could impact the bottom line as much as any reimbursement rate increase.