1upHealth submits our commentary on CMS’ Advancing Interoperability and Improving Prior Authorization Processes Proposed Rule

Public comment periods are typically 30 days when CMS opens a document for public comment. Members of the public are encouraged by CMS to use the comments process to seek clarification of posted information, to provide additional information that may be useful in the decision making process, and to provide informed opinions on the subject under consideration. 

Dr. Rucker’s Letter to CMS

March 13, 2023 

The Honorable Chiquita Brooks-LaSure  

Administrator 

Centers for Medicare & Medicaid Services  

U.S. Department of Health and Human Services  

200 Independence Avenue, SW  

Washington, DC 20201  

Cc: Alexandra Mugge, Lorraine Doo 

Re: CMS-2022-0190-0002 Advancing Interoperability and Improving Prior Authorization  Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State  Medicaid Agencies, etc. (Docket CMS-0057-P) 

Docket RIN 0938-AU87 

Dear Administrator Brooks-LaSure: 

This comment is by 1upHealth, a scalable serverless cloud data provider leveraging the power of the FHIR data standard to combine claims and clinical data for analytics and APIs. We strongly applaud the work of CMS to improve the ability to make the healthcare delivery system more efficient by harnessing modern computing to robustly enable FHIR APIs (application programming interfaces) to connect patients, providers and payers. We applaud the work to start developing computational accountability and automation for prior authorization. We are concerned with adding CMS payment incentives for TEFCA. TEFCA uses a 1990’s document-based architecture (back when the Internet was serving only pages) and would incent a largely non-computable architecture which does not allow today’s apps, software tools and ability access to individual data fields. TEFCA’s “one document at a time” brokered architecture does not support the computing needed for value, quality, population health and pandemic surveillance. 

Payer APIs for Patients, Providers and other Payers 

We strongly support CMS’s insight that payers are in a unique position with rich longitudinal information on the totality of a patient’s care. They should be required to share that with patients, their providers and other payers. The use of computable FHIR API standards maximizes the chances for innovation by all. The proposed revision of the Payer APIs provides technical clarity to payers.  

The new Payer-to-Provider FHIR APIs may be the most heavily used of the three classes of payer APIs and are central to provide real-time care coordination and value-based care. Today population health is based on stale data abstraction approaches which limit the scope and salience  of clinical outreach and force interactions to be largely “manual. With Payer-to-Provider APIs providers will have near real-time confidence to understand the care their patient has received. Having this API data be available on an “opt out” basis is important because often elderly Medicare  beneficiaries or at-risk Medicaid patients are not able to provide the consent  they would provide if  healthy.  

We ask that Payer-to-Payer and Payer-to-Provider APIs use the HL7 Bulk FHIR standard. This standard was designed to provide population level data. By incenting use of the Bulk FHIR standard, payers and providers will be able to analyze care using the tools of “big data” analytics and gain richer insights into value than is possible with today’s narrower quality metrics. 

Prior Authorization and a Roadmap for Automation 

The proposal to provide PA requests and decisions including reasons for denial is a needed step to reduce patient burden and the need to undergo repetitive and care-delaying PA. With medications a large part of PA, we encourage the addition of medications to this rule. Reporting of PA  decisions is a relatively straightforward technical requirement and FHIR accelerators can handle  the data standardization of these simple Boolean or text data fields.  

Automation of prior authorization in the FHIR Prior Authorization Requirements, Documentation and Decision API is a more complicated process. The informatics challenge is that clinical conditions addressed by prior authorization can be complex. Large amounts of clinical information may have to be examined and much of that data is not standardized or structured. The question for each component of PARDD is what data needs to be captured and shared.  

Coverage requirements discovery (CRD) requires knowledge of the payer and the service to be covered and can be handled by current payment codes. CRD API requirements could be incorporated by January 2026.  

Documentation Templates and Rules is more complicated but the API from the payer to the provider could use SMART on FHIR. Knowledge representation tasks for thousands of individual disease / treatment combinations will be large. Readiness of EMRs to respond with SMART on FHIR data is unclear. We also encourage CMS to require that prior authorization decisions be based on publicly available algorithms rather than private IP requiring licensing fees.  

Prior Authorization Support (PAS per the DaVinci FHIR accelerator work) would appear to subsume the current X12 278 standard and could be implemented independently of X12 transactions. PAS is dependent on the overall prior authorization context and how it would fit in with current HIPAA mandated EDI. Part of the appeal of modern RESTful FHIR approaches is the ability to use simple directory services and avoid the cost and overhead of claims clearinghouses. 

RFI for TEFCA in CMS Interoperability Incentive Programs

The RFI requests information on providing incentives for TEFCA under the MIPS Promoting Interoperability and Medicare Promoting Interoperability Programs. For context, TEFCA uses an architecture based on the pre-app, pre-RESTful, pre-JSON, pre-FHIR computing of the 1990s. Today, we have the opportunity to support deep interoperability digitally not just static medical record transfer. We encourage CMS to avoid inadvertently shifting incentives in a technologically backward direction.  

The proposed rule frames a choice between modern API driven robust interoperability and older style document exchange. The history of IHE on which TEFCA relies reflects the evolution of the Internet which in the 1990’s was largely page retrieval with limited computing. TEFCAs architecture reflects this older limited capability. Any computing on data obtained via TEFCA requires computationally complex negotiation with a QHIN and then parsing each document. Practically there is not field level data access. By comparison, today with field level data, the Internet can support massive computing including entire app environments such as Google Docs and the  Adobe Suite. The modern APIs which globally power most phone apps often use the same straightforward RESTful protocols and JSON data streams used in FHIR APIs.  

TEFCAs IHE protocol architecture has a number of other limitations. It has no ability to generate population level queries for provider performance or pandemic surveillance as the document is intrinsically patient specific – TEFCA cannot query every document for every patient.  

With the TEFCA RFI question, CMS appears to be pondering directly opposite interoperability approaches within the proposed rule. Ultimately there are limited amounts of resources for interoperability work and supporting conflicting standards would materially negate the years of work the HL7 community has performed in advancing interoperability. 

Further Considerations of Data Models 

Increasingly healthcare computing is moving from the CCDA healthcare data model to the FHIR  data model which was designed to replace CCDA. Over time having more structured and individually retrievable data allows for greater efficiency at each computational touch point whether  that is for clinical decision alerts, quality measurement, equity analysis, network design, fraud  detection, appropriateness analysis, patient empowerment, alleviating unfavorable social  determinants of health or any other activity where computing with algorithms can help.  

Interoperability in any endeavor is a combination of transmission protocols and the nature of the data payload. There has been discussion of “converting” TEFCA to use FHIR but it should be noted that unlike the simple RESTful protocol, using FHIR as a payload in TEFCA, wouldn’t address the IHE transmission protocol which does not support fine-grained access. Rework of TEFCA for FHIR would also require major bespoke healthcare only programming in every EMR. 

Current TEFCA and QHIN plans require new sets of APIs both for generating and responding to patient record requests. It would be simpler to go directly to FHIR, JSON, and RESTful APIs as in the payer APIs sections of the proposed rule and as the rest of the computing world has done rather than build out a duplicative structure and to then attempt to rebuild it in one to three years using FHIR. CMS should hold off on TEFCA incentives and provider requirements that will require full software rebuilds until TEFCA has shown it can effectively use FHIR.  

TEFCA’s QHIN brokerage architecture does not fundamentally reduce the cost to the system of finding medical records since users of either FHIR APIs or QHIN brokers still both need to do the broadcast or directed query localization of record sources. CMS’s National Directory of Health Care Providers and Services can provide these electronic endpoints at much lower cost and they could be used by anyone whether for FHIR APIs or document retrieval. 

CMS should also consider workforce availability as it considers whether to incentivize use of TEFCA. Unlike FHIR APIs which are built upon and use of broadly understood programming approaches and software designs, TEFCA requires arcane healthcare-only programming skills. Unique to healthcare approaches raise costs by requiring programming be done by the few programmers who specialize in these increasingly obsolete skill sets.  

Equity and Competition Considerations with TEFCA 

The cost of care is the single largest barrier to equity in healthcare. While how to address costs  has been the subject of ongoing debate, there is general agreement that lowering transaction costs and facilitating competition to lower prices are valuable. We urge CMS to analyze whether networks designed to link incumbent EHRs while effectively disadvantaging new competitors by mandated use of brokers optimizes public policy. Using modern widely available FHIR APIs avoids the mandated use of brokers who ultimately will only be able to connect incumbent EMR products. The closed nature of TEFCA is also hinted at by the failure of the involved parties to use globally accepted standards organizations and instead maintain control within entities historically affiliated with legacy EMR vendors rather than the broader community of potential competitors. 

We believe equity and efficiency in US healthcare will be best served by allowing new business models and 7 by 24 connected care with modern web architectures not by furthering exchange of one-document one-patient at a time snippets of incumbent EMR office visit or hospital charts. Unambiguous support for the FHIR APIs which are included in the first section of the proposed rule should be the focus of interoperability. FHIR APIs have vast potential to improve patient satisfaction, enhance quality and lower cost as modern computing has done throughout the non healthcare economy.  

Sincerely, 

Donald W. Rucker, MD 

Chief Strategy Officer, 1upHealth

To learn more about 1upHealth’s point of view on the latest CMS proposed ruling, make sure to visit our Resource Center.