Plate tectonics and the new CMS prior authorization rule | Viewpoint

Roughly 100 years ago, Alfred Wegener postulated that the continents were not in fact fixed, but were actually moving. This hypothesis was confirmed as maps illustrated how the bulge in Brazil separated from the west coast of Africa.

Don Rucker, MD

Today, there are also slow but large movements in how CMS pays for healthcare. The “continental” division of CMS programs from just Medicare Fee for Service in 1965 into classic Medicare, Medicare Advantage, Medicaid and the Exchanges has generated multiple fault lines as well.

CMS must weave the dominating incentives in each of these payment programs into a pattern of cost-effective and clinically appropriate care at the individual level and for the entire population – the “triple aim.”

CMS just released a Prior Authorization and Interoperability Rule (CMS-0057F) aiming to both make care more effective, more informed, and more transparent through multiple payer application programming interface (API) mandates. Transparency in this rule largely focuses on the allocation of care via “prior authorization.” The rule applies to payers in the CMS orbit – Medicare Advantage, Medicaid, CHIP and exchange plans.

Prior authorization has generated a large amount of controversy and is an ongoing hotspot in American healthcare – much like the geologic hotspot that formed Hawaii. Prior authorization seeks to selectively tamp down use of medical care and services but adjusting the “amount of use knob” requires complex clinical and economic calculations.

Determining the best clinical care is potentially unknowable and tuning the moral hazards of providers who want to provide more care and capitated payers who want less care to pay for is an existential dilemma.

So, who has to do what to both comply with the rule and use the rule to maximize opportunities in this digital version of plate tectonics?

For payers, the rule is clear: payers need to add their current ‘payer to patient’ API similar - but not quite identical – APIs for ‘payer to provider’ and ‘payer to payer’ data exchange.

Among other requirements, APIs need to provide various versions of a patient’s prior authorization history and will have for payer-provider API patient opt-out as the consent baseline and for the payer-to-payer API patient opt-in as a consent requirement. Payers may have to refactor their prior authorization pipelines to meet the 72-hour expedited/7 business days standard decision timelines and publicly report details on performance here.

There is also a requirement for a Prior Authorization API – what will be required to be transmitted here is a work in progress as API tech standards, in particular the FHIR Prior Authorization protocols, evolve.

Since this is a CMS rule, it largely deals with payers, but it does provide “Promoting Interoperability” incentives for physicians and hospitals. The rule requires some digital use of a PA API by physicians and hospitals covered by prior authorization. CMS has noted that ONC will take the lead on defining the provider side of the APIs to access payer data and interact with payers on prior authorization requests and decision making.

However, focusing on API compliance misses the intended momentum and likely further incentives which are all to increase value in healthcare. Modern value creation (and measurement and reporting) is increasingly digital. Coordinating care, harnessing the quantified self on one’s phone, tracking interventions to minimize harm from the metabolic syndrome (e.g. Type 2 diabetes, elevated lipids, hypertension, obesity), and medication compliance can all be performed at a much higher continuous level with a fully computable digital platform as compared to today’s intermittent doctor’s office and EHR-based care.

One can look at these rules as isolated API and prior authorization requirements on whatever side of the API one is on (payers on one side, providers and patients and their apps on the other) but the real way to navigate this rule is not to focus on the API but to look at the underlying intent. That underlying intent is to drive value in healthcare. When focusing on value, the conversation shifts away from the APIs and toward what is underneath these APIs.

What is underneath and powering these APIs are potentially vast amounts of data, including both clinical AND financial (claims) data. Value is the combination of what you purchase and what you pay for. If payers and providers want to truly use digital data, they need to operate with deep awareness of both claims and clinical data.

Historically, payers have had population level claims data (think claims engines) and providers have had population level clinical data (think the EHR). Both payers and providers will need to rethink their enterprise software architectures to not just use the APIs to get full sets of claims and clinical data, but to COMPUTE for better and more efficient care with that data. A claims engine or an EHR backed up with an enterprise data warehouse (EDW) will be insufficient.

Fortunately, today we have the tools to make this possible. FHIR unifies clinical and claims data in a single software standard while cloud computing provides the rich storage and compute tools to use that data and they can power any manner of API (including far beyond the CMS and ONC requirements) to interact globally with patients and providers.

While earthquakes and volcanoes are intermittent indicators of the geology underneath us, one can be certain there will be constant regulatory and legislative activity spurring digital transformation of care to drive value until we get an entire redesign of U.S. healthcare.

Don Rucker, MD, is chief strategy officer of 1upHealth.