Mr. Health API Guy Goes to Washington

Or How I Learned to Stop Memeing and Love the Formal Comment

I’m going to keep this one nice and brief, as there’s a good chunk of content coming from in the next month or so. After getting on the soapbox and opining a bit on the state of regulation in Pondering the Health Policy Orb, my friend Mr. Aneesh Chopra and I got together to put together a more formal comment on the Request for Information from the ONC regarding Prior Authorization.

It was a nail-biting buzzer-beater to get it in before the comment period ended (hey, topical March Madness reference), but ultimately was able to participate in some of the regulatory machinery that underpins our great nation’s democracy (which looks surprisingly akin to a very polite and well-mannered comment section of Reddit).

I’m also very grateful to Aneesh and the CareJourney team (shout out to Catherine) for their time working on this together. You can check out that commentary here or in the full text below.

In any case, as we look forward to what may come from this RFI and other government edicts over the next 1-3 years, it seems we sit on the precipice of the next great regulatory era of United States healthcare policy - one with a distinct focus on improving provider and payer interactions. So make sure to do your civic duty and participate actively in whatever’s next to come.

---

Background and Summary 

In December 2020, the Centers for Medicare & Medicaid Services (CMS) released the CMS Interoperability and Prior Authorization Proposed Rule, which built upon the foundational concepts from the CMS Interoperability and Patient Access Final Rule from earlier that year to improve health information exchange between payers, providers, and patients. In addition to refining some outstanding detail missing from the Patient Access rule, this rule focused on possible requirements for regulated payers in regards to electronic prior authorization capabilities. 

With the change of administration, this rule was not finalized in 2021, but in January 2022, the Office of the National Coordinator (ONC) issued an Request for Information (RFI) seeking input from the public on electronic prior authorization standards, specifically to inform future rule making in regards to prior authorization capabilities in the ONC Health IT Certification Program. 

We support the principles and goals of the CMS Proposed Rule. We also believe that the RFI correctly identified the key steps that need to happen in order to complete a prior authorization: 

1. Identify when prior authorization is applicable for an item or service, using clinical decision support and/or user input, and for receiving notifications of changes in such applicability; 

2. Query a payer API for prior authorization requirements for each item and service and identify in real time specific rules and documentation requirements; 

3. Collect clinical and administrative documentation needed to complete prior authorization documentation (electronic forms or templates) from a health IT system; 

4. Electronically submit completed documentation for prior authorization to a payer's API, along with supporting information; 

5. Receive a response from a payer regarding approval, denial (including a reason for denial), or need for additional information; 

However, for ONC and CMS to realize the potential of these policies and to ensure successful adoption and usage across payers and providers, we strongly encourage an implementation plan focused on industry proven technologies, re-use of foundational deployed (regulated) capabilities, and open standards, as we will describe in the solution below. 

Requirements for Widespread and Successful Adoption of Prior Authorization Infrastructure 

Proven technologies -  The proposed rule by CMS references the Coverage Requirements Discovery (CRD) and Documentation Templates and Rules (DTR) FHIR Implementation Guides in Prior Authorization Documentation Lookup Requirement API. We recognize the impressive work of the DaVinci Project in accelerating standards development and testing of these guides, the Argonaut Project in facilitating consensus-building work on enabling capabilities such as Clinical Decision Support Hooks (CDS Hooks), and CMS’ long-standing support for Clinical Quality Language (CQL). However, we are concerned about the limited number of real-world deployments where these technologies have been market tested. To that end, we strongly encourage ONC/CMS to facilitate more real-world testing in a multi-stakeholder, cross-enterprise, and federated environment in order to close feedback loops that might lower implementation burden. For example, we may surface gaps, including the need to add FHIR “write” capabilities within an EHR to close the loop on payer-approved clinical orders. Otherwise, we fear providers and payers might struggle with implementation, exceeding cost assumptions and weakening projected benefits.

Open standards - The HL7 FHIR standard is open source, fully discoverable and usable without licensing or IP constraints. The openness of this standard has allowed unprecedented participation in the development and deployment of innovative new technologies, as well as the rapid adoption of this format compared with previous generations of standards. We believe that federal and state policies built upon open standards further bolster this participation by regulated organizations and innovation by new entrants. Where feasible, ONC/CMS should prioritize the use of open standards for regulation. 

Re-use of foundational deployed capabilities - Disparate functional capability requirements have a higher cost of implementation. Additionally, disparate functional requirements leave affected organizations with a large surface area of support and maintenance, leaving minimal capacity for improvement. Where possible, we believe that re-use of deployed capabilities, such as the existing production FHIR servers that payers deployed to meet Patient Access APIs, and similar adoption of Cures Act certified EHRs should accelerate overall adoption speed while reducing cost of implementation and maintenance. 

Building on Patient Access API Standards 

In order to accomplish the key steps the ONC outlined in the RFI and to further the principles put forth in the Cures Act, the regulatory policy for prior authorization should continue to have a focus on open access to data by necessary parties without special effort. To that extent, physician access to payer APIs (the Provider Access API in the CMS Proposed Rule) is a necessary first step and phase in the prior authorization process. Ensuring that physicians have a full and comprehensive view of their patient is absolutely vital to informed decision making. Furthermore, we believe that this represents a relatively modest investment, such as for example a “bulk” FHIR authorization layer on top of the existing FHIR capabilities from the Patient Access rule, relies entirely on open standards, and has been proven in the industry via the CMS’ Data at the Point of Care program. As a reminder, CMS enabled consumer application access to “Blue Button” and re-used the “Beneficiary FHIR Database” in combination with a“bulk” FHIR authorization server in order to support physician access. Thus, we recommend prioritizing the deployment of this capability above all else. 

We also believe that some marketplace guidelines and guardrails about authorization of a plan app and a provider app on both sides will be necessary. The adoption of patient facing applications using Patient Access APIs has seen significant obstacles due to inconsistent application approval and onboarding processes, to the extent some applications have been blocked from connectivity. We urge the CMS/ONC to design a model contract for payer-designated SMART on FHIR apps to access provider electronic health records for use without special effort for the purpose of providing data for quality measure reporting, care gap closures, risk adjustment; prior authorization, and SDOH data sharing. We recommend that the CMS and ONC review the Application Registration Guide created by the CARIN Alliance as a template and example of relevant principles. 

Beyond these first two steps, we believe that a novel path forward based on real-world testing of SMART apps on both the payer/provider side (that are otherwise subject to contractual negotiation for application access terms) would best lead to successful industry adoption of electronic prior authorization. We encourage the ONC and CMS to consider the use of open standards such as FHIR in all aspects of exchange as is currently available via a HIPAA Exception for Da Vinci pilot participants.

To help explain the benefits of this approach, we thought to illustrate how “MacGyver” would accomplish electronic prior authorization on the foundation of existing deployed functionality that might be repurposed from other use cases. Let’s presume either of two approaches - a set of transactions within a single payer/provider SMART on FHIR app, or an orchestration of payer-designated and provider-designated SMART on FHIR apps. The first step would be for a physician to register an application of his or her choice with a payer API for the purposes of determining whether or not a service requires prior authorization. If needed, the payer could similarly require application access to the provider’s EHR in order to pre-populate answers to questions (ie., clinical data in the form of USCDI) needed to adjudicate the request. Alternatively, Payers could surface additional questions inside of the provider's app via the Argonaut Project-endorsed Questionnaire resource to capture the minimum data necessary to finalize the authorization determination. The manner in which questionnaire items are pre-filled should be left out of scope for this first round of regulations, rather than focusing exclusively on CQL as the DaVinci DTR specification currently does. This way industry can innovate based on various techniques including shared access to USCDI FHIR APIs, structured logic expressions like CQL, and machine learning techniques leveraging questionnaire item metadata. The resulting decision could be written into the EHR as a pending order for a physician to consider, with incremental FHIR standards development building upon existing “write” initiatives such as the 2021 Argonaut Project. 

Finally, we believe it is imperative that patients directly benefit from greater transparency throughout this process. We encourage CMS and ONC to upgrade the payer Patient Access API requirements to include a new functional requirement to include as part of the existing consumer application access provisions any prior authorization status updates. For example, payers may post FHIR documents to reflect the outcomes of an adjudicated prior authorization request. 

We look forward to a collaborative industry and government effort on the rollout of prior authorization capabilities across payers and providers nationwide. 

Sincerely, 

Aneesh Chopra - President, CareJourney 

Brendan Keeler - Product Manager, Zus Health