Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria, 3475-3481 [2022-01309]

Agencies

• DEPARTMENT OF HEALTH AND HUMAN SERVICES
• Office of the Secretary

[Federal Register Volume 87, Number 15 (Monday, January 24, 2022)]
[Proposed Rules]
[Pages 3475-3481]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2022-01309]


=======================================================================
-----------------------------------------------------------------------

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN-0955-AA04


Request for Information: Electronic Prior Authorization 
Standards, Implementation Specifications, and Certification Criteria

AGENCY: Office of the National Coordinator for Health IT, Health and 
Human Services (HHS).

ACTION: Request for information

-----------------------------------------------------------------------

SUMMARY: This request for information seeks input from the public 
regarding electronic prior authorization standards, implementation 
specifications, and certification criteria that could be adopted within 
the ONC Health IT Certification Program. Responses to this Request for 
Information will be used to inform potential future rulemaking.

DATES: To be assured consideration, written or electronic comments must 
be received at one of the addresses provided below, no later than 5 
p.m. on March 25, 2022.

ADDRESSES: You may submit comments, identified by RIN 0955-AA04, by any 
of the following methods (please do not submit duplicate comments). 
Because of staff and resource limitations, we cannot accept comments by 
facsimile (FAX) transmission.
    Federal eRulemaking Portal: Follow the instructions for submitting 
comments. Attachments should be in Microsoft Word, Microsoft Excel, or 
Adobe PDF; however, we prefer Microsoft Word. https://www.regulations.gov.
    Regular, Express, or Overnight Mail: Department of Health and Human 
Services, Office of the National Coordinator for Health Information 
Technology, Attention: Request for Information: Electronic Prior 
Authorization Standards, Implementation Specifications, and 
Certification Criteria, Mary E. Switzer Building, Mail Stop: 7033A, 330 
C Street SW, Washington, DC 20201. Please submit one original and two 
copies.
    Hand Delivery or Courier: Office of the National Coordinator for 
Health Information Technology, Attention: Request for Information: 
Electronic Prior Authorization Standards, Implementation 
Specifications, and Certification Criteria, Mary E. Switzer Building, 
Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit 
one original and two copies. (Because access to the interior of the 
Mary E. Switzer Building is not readily available to persons without 
Federal Government identification, commenters are encouraged to leave 
their comments in the mail drop slots located in the main lobby of the 
building.)
    Inspection of Public Comments: All comments received before the 
close of the comment period will be available for public inspection, 
including any personally identifiable or confidential business 
information that is included in a comment. Please do not include 
anything in your comment submission that you do not wish to share with 
the general public. Such information includes, but is not limited to: A 
person's social security number; date of birth; driver's license 
number; state identification number or foreign country equivalent; 
passport number; financial account number; credit or debit card number; 
any personal health information; or any business information that could 
be considered proprietary. We will post all comments that are received 
before the close of the comment period at https://www.regulations.gov.
    Docket: For access to the docket to read background documents or 
comments received, go to https://www.regulations.gov or the Department 
of Health and Human Services, Office of the National Coordinator for 
Health Information Technology, Mary E. Switzer Building, Mail Stop: 
7033A, 330 C Street SW, Washington, DC 20201 (call ahead to the contact 
listed below to arrange for inspection).

FOR FURTHER INFORMATION CONTACT: Alex Baker, Office of Policy, Office 
of the National Coordinator for Health Information Technology, 202-260-
2048.

SUPPLEMENTARY INFORMATION:

I. Background

    For purposes of this Request for Information (RFI), prior 
authorization generally refers to rules imposed by healthcare payers 
that require approval for a medication, procedure, device, or other 
medical service be obtained prior to payment for the item or service. 
Prior authorization requirements are established by payers to help 
control costs and ensure payment accuracy by verifying that an item or 
service is medically necessary, meets coverage criteria, and is 
consistent with standards of care. Stakeholders have stated that 
diverse payer policies, provider workflow challenges, and technical 
barriers create an environment in which the prior authorization process 
is a source of burden for patients, providers, and payers; a cause of 
burnout for providers; and a health risk for patients when it delays 
their care.\1\
---------------------------------------------------------------------------

    \1\ For additional discussion of administrative burden 
associated with the prior authorization process, see the CMS 
Interoperability and Prior Authorization proposed rule at 85 FR 
82606.
---------------------------------------------------------------------------

    ONC's Strategy on Reducing Regulatory and Administrative Burden 
Relating to the Use of Health IT and EHRs,\2\ released in 2020, 
identified challenges associated with the prior authorization process, 
including: (i) Difficulty in determining whether an item or service 
requires prior authorization; (ii) difficulty in determining payer-
specific prior authorization requirements for those items and services; 
(iii) inefficient use of provider and staff time to navigate 
communications channels such as fax, telephone, and various web 
portals; and

[[Page 3476]]

(iv) unpredictable and lengthy amounts of time to receive payer 
decisions. The Strategy notes that payers and health IT developers have 
addressed prior authorization in an ad hoc manner with interfaces that 
reflect individual payer technology considerations, payer lines of 
business, and customer-specific constraints. In order to address these 
issues, the Strategy included a number of recommendations to strengthen 
electronic prior authorization processes, such as: Leveraging health IT 
to standardize data and processes around ordering services or 
equipment; coordinating efforts to advance new standards approaches; 
and incentivizing adoption and/or use of technology that can generate 
and exchange standardized data to support documentation needs.
---------------------------------------------------------------------------

    \2\ Office of the National Coordinator for Health Information 
Technology. Strategy on Reducing Regulatory and Administrative 
Burden Relating to the Use of Health IT and EHRs [PDF file]. 
February 2020. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.
---------------------------------------------------------------------------

    In order to further explore these and other stakeholder 
recommendations, and to build on recent efforts related to electronic 
prior authorization, we seek public comments on how the ONC Health IT 
Certification Program (Certification Program) could incorporate 
standards, implementation specifications, and certification criteria to 
advance electronic prior authorization.

a. ONC Health IT Certification Program

    The Certification Program \3\ is a voluntary program under which 
health IT developers can obtain ONC certification for their health IT 
products. Requirements for certification are established by standards, 
implementation specifications, and certification criteria adopted 
through rulemaking by the Secretary. The Certification Program does not 
set any requirements for healthcare providers but supports the 
availability of certified health IT for use by healthcare providers 
under other federal, state, and private programs.
---------------------------------------------------------------------------

    \3\ For more information, see https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program.
---------------------------------------------------------------------------

    The Certification Program currently addresses electronic prior 
authorization for medications as part of the ``electronic prescribing'' 
certification criterion at 45 CFR 170.315(b)(3). On May 1, 2020, ONC 
published in the Federal Register the ``21st Century Cures Act: 
Interoperability, Information Blocking, and the ONC Health IT 
Certification Program'' final rule (21st Century Cures Act final rule). 
In this rule, ONC adopted the National Council for Prescription Drug 
Programs (NCPDP) SCRIPT Standard, Version 2017071, for electronic 
prescribing and specified electronic prior authorization transactions 
supported by the standard as optional transactions which health IT 
developers may support in their products (85 FR 25678). However, the 
Certification Program does not yet address electronic prior 
authorization for other items and services that healthcare consumers 
may seek to obtain. Accordingly, for the purposes of this RFI, we are 
interested in certified health IT functions not yet included under the 
Certification Program that can support electronic prior authorization 
processes for items and services other than medications.
    In the 21st Century Cures Act final rule, ONC also finalized a new 
certification criterion at Sec.  170.315(g)(10), ``standardized API for 
patient and population services,'' to support the availability of 
secure, standards-based application programming interfaces (APIs) in 
certified health IT products. This criterion requires the use of FHIR 
Release 4.0.1 and several implementation specifications (85 FR 25742). 
Under the API Maintenance of Certification Requirement for the ONC 
Health IT Certification Program at Sec.  170.404(b)(3), Certified API 
Developers (as defined in Sec.  170.404(c)) with API technology 
previously certified to the criterion in Sec.  170.315(g)(8) must 
provide API technology certified to Sec.  170.315(g)(10) to all API 
Information Sources (as defined in Sec.  170.404(c)) deployed with 
certified API technology no later than December 31, 2022 (85 FR 70072). 
As discussed in the 21st Century Cures Act final rule, we believe the 
availability of standards-based API functionality in provider EHR 
systems is an important step towards increased interoperability across 
the healthcare system (85 FR 25740). While the initial use case for 
this criterion has focused on patients' access to their health 
information, we believe this functionality can support a wide range of 
use cases including research, public health, quality measurement, and 
healthcare operations, including prior authorization processes.

b. Requirements Under HIPAA for Electronic Prior Authorization 
Transaction Standards

    Pursuant to the Health Insurance Portability and Accountability Act 
of 1996 (HIPAA), the Secretary must adopt electronic standards for use 
by ``covered entities,'' which is defined as including health plans, 
healthcare clearinghouses, and certain healthcare providers. The two 
standards adopted for referral certification and authorization 
transactions under HIPAA (Sec.  162.1302) include: NCPDP Version D.0 
for retail pharmacy drugs; and X12 Version 5010x217 278 (X12 278) for 
dental, professional, and institutional request for review and response 
for items and services. The X12 275 standard, which is used to transmit 
additional documentation to health plans, is not currently mandated 
under HIPAA, but it may be used to support the exchange of the 
additional information that is required for prior authorization. Though 
payers are required to accept the X12 278 standard for electronic prior 
authorization transactions when transmitted by a provider, and 
providers have been encouraged to conduct the transaction 
electronically, an annual survey conducted by the Council for 
Affordable Quality Healthcare has found that the prior authorization 
transaction standard, and electronic prior authorizations in general, 
have not been widely used.\4\
---------------------------------------------------------------------------

    \4\ See https://www.caqh.org/sites/default/files/explorations/index/2020-caqh-index.pdf.
---------------------------------------------------------------------------

    HIPAA also requires that HHS adopt operating rules for the HIPAA 
standard transactions. Operating rules are defined at Sec.  162.103 as 
the ``necessary business rules and guidelines for the electronic 
exchange of information that are not defined by a standard or its 
implementation specifications as adopted for purposes of HIPAA 
Administrative Simplification.'' The National Committee on Vital and 
Health Statistics (NCVHS) reviews the operating rules developed by 
certain entities and advises the Secretary as to whether HHS should 
adopt them (section 1173(g)(3) of the Social Security Act). The 
Secretary adopts operating rules by expedited rulemaking in accordance 
with section 1173(g)(4) of the Social Security Act. To date, HHS has 
adopted operating rules for three HIPAA transactions: Eligibility for a 
health plan, healthcare claim status (76 FR 40458), and healthcare 
electronic funds transfers (EFT) and remittance advice (77 FR 
48008).\5\
---------------------------------------------------------------------------

    \5\ For more information on operating rules, see https://www.caqh.org/core/operating-rules.
---------------------------------------------------------------------------

c. Recent Efforts To Advance Electronic Prior Authorization Processes

    Several recent HHS efforts have focused on concerns about prior 
authorization, core technical and policy barriers, and approaches to 
improve prior authorization processes and reduce burden.
    The Health Information Technology Advisory Committee (HITAC), 
established under section 3002 of the Public Health Service Act, has 
addressed prior authorization on several occasions. In October 2019, 
the HITAC

[[Page 3477]]

put forth recommendations establishing Interoperability Standards 
Priority Target Areas and identified a ``need for standards to support 
the integration of prior authorization into all applicable EHR-based 
ordering workflows.'' \6\ In 2020, ONC charged the HITAC with 
establishing the Intersection of Clinical and Administrative Data 
(ICAD) Task Force in order to produce information and recommendations 
on the merging of clinical and administrative data. The ICAD Task 
Force, which included members of the HITAC and NCVHS, industry 
stakeholders, and the public, explored a wide range of topics, 
including transport and exchange structures; areas for clinical and 
operations data alignment; and privacy and security rules and 
protections.
---------------------------------------------------------------------------

    \6\ HITAC recommendations on priority target areas, October 16, 
2019: https://www.healthit.gov/sites/default/files/page/2019-12/2019-10-16_ISP_TF_Final_Report_signed_508.pdf.
---------------------------------------------------------------------------

    The ICAD Task Force's final recommendations \7\ to the HITAC 
included a recommendation to ``Establish Standards for Prior 
Authorization Workflows.'' Specifically, the final report recommended 
that ONC work with CMS, other federal actors, and standards development 
organizations to ``develop programmatic . . . specifications to create 
an authorization . . . such that the authorization and related 
documentation can be triggered in the relevant workflow system where 
the triggering event for the authorization is created.'' The Task Force 
emphasized that a future standards ecosystem for prior authorization 
should ``allow for standards development and evolution, so as to not 
preclude innovation, while including a `floor' of standards to promote 
rapid adoption through common implementation.'' This approach can 
enable broad participation among stakeholders while avoiding 
unnecessary barriers for those who wish to innovate. It can also 
provide for rapid innovation and piloting, testing, and validation of 
new tools and standards to meet evolving needs. The final report also 
provided an overview of existing and emerging standards available to 
support prior authorization workflows. This included discussion of 
several HL7[supreg] FHIR[supreg] Implementation Guides (IGs) for 
exchange of prior authorization information, including the HL7[supreg] 
FHIR[supreg] Da Vinci Coverage Requirements Discovery (CRD), 
Documentation Templates and Coverage Rules (DTR), and Prior 
Authorization Support (PAS) IGs, which are discussed in more detail 
below.
---------------------------------------------------------------------------

    \7\ Final Recommendations of the ICAD Task Force, November 2020: 
https://www.healthit.gov/sites/default/files/facas/ICAD_TF_FINAL_Report_HITAC_2020-11-06_0.pdf.
---------------------------------------------------------------------------

    In December 2020, the Centers for Medicare & Medicaid Services 
(CMS) released a notice of proposed rulemaking titled ``Reducing 
Provider and Patient Burden by Improving Prior Authorization Processes, 
and Promoting Patients' Electronic Access to Health Information for 
Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and 
CHIP Managed Care Entities, and Issuers of Qualified Health Plans on 
the Federally Facilitated Exchanges'' (85 FR 82586, hereafter the 
Interoperability and Prior Authorization proposed rule). In that 
proposed rule, CMS proposed to require Medicaid Managed Care Plans, 
State Medicaid Agencies, Children's Health Insurance Program (CHIP) 
Agencies and CHIP Managed Care Entities, and Issuers of Qualified 
Health Plans on the Federally-Facilitated Exchanges (impacted payers), 
to establish standards-based APIs to streamline the process of 
submitting prior authorization requests and reduce burden on both 
providers and payers. Specifically, CMS proposed to require impacted 
payers to implement and maintain: (i) A Documentation Requirement 
Lookup Service API to enable providers to determine which items and 
services need a prior authorization and what documentation is needed to 
submit the prior authorization request (85 FR 82608); and (ii) a Prior 
Authorization Support API to facilitate transmission of prior 
authorization requests and decisions while maintaining alignment with, 
and facilitating the use of, HIPAA transaction standards (85 FR 82609).
    In the same notice of proposed rulemaking, ONC issued the ``Health 
Information Technology Standards and Implementation Specifications'' 
proposed rulemaking (85 FR 82632; hereafter the ONC Healthcare 
Operations Standards proposed rule), in which ONC proposed to adopt the 
implementation specifications referenced in CMS' proposals (85 FR 
82632-33), including the HL7[supreg] FHIR[supreg] CRD, DTR, and PAS IGs 
supporting the two API proposals related to prior authorization. ONC 
proposed these specifications for adoption by HHS as part of a 
nationwide health IT infrastructure supporting burden reduction, 
healthcare cost reduction, and improved care quality.
    As part of the Interoperability and Prior Authorization proposed 
rule, CMS did not propose to require providers to interact with the 
proposed payer APIs to conduct prior authorization activities. Instead, 
CMS stated its belief that providers would adopt the technology and 
workflows needed to take advantage of these APIs on a voluntary basis 
over time, following updates by health IT developers to electronic 
health record systems and related tools. CMS requested comment on 
additional ways to encourage implementation of these functions in EHRs, 
including the adoption of certification criteria in the ONC Health IT 
Certification Program (85 FR 82610). In response to this request for 
comment, many stakeholders expressed support for HHS advancing EHR 
functionality to enable seamless exchange of information facilitating 
prior authorization.
    While CMS continues to consider the proposals put forth in the 
Interoperability and Prior Authorization proposed rule and public 
comments received thereon, we believe there are additional steps which 
HHS could explore to improve electronic prior authorization 
capabilities within health IT systems. Based on stakeholder input, 
including the recommendations of the ICAD Task Force, we also believe 
there is strong support across healthcare industry stakeholders for 
additional action.

d. Functional Capabilities for Electronic Prior Authorization in 
Certified Health IT

    We are seeking comment on functional capabilities for electronic 
prior authorization that should be considered for inclusion in 
certified health IT. Specifically we are seeking comment on a core set 
of capabilities that would enable a certified Health IT Module or 
Modules to:
     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;
     Query a payer API for prior authorization requirements for 
each item and service and identify in real time specific rules and 
documentation requirements;
     Collect clinical and administrative documentation needed 
to complete prior authorization documentation (electronic forms or 
templates) from a health IT system;
     Electronically submit completed documentation for prior 
authorization to a payer's API, along with supporting information;
     Receive a response from a payer regarding approval, denial 
(including a reason for denial), or need for additional information;
     Query a payer's system for updates on a pending prior 
authorization request and have a reason returned as to why a request is 
still pending; and

[[Page 3478]]

     Effectively capture and persist digital signatures (or 
other indications of provider review and assent), enable data integrity 
of documentation over time, and support other features necessary to 
meet payer administrative requirements associated with prior 
authorization transactions.
    We invite further comment on whether these are the appropriate 
minimum capabilities needed for certified health IT systems to 
successfully interact with payer systems to complete key electronic 
prior authorization activities.

e. Implementation Specifications To Support Electronic Prior 
Authorization Capabilities

    As noted above, in the ONC Healthcare Operations Standards proposed 
rule ONC proposed to adopt, on behalf of HHS, three implementation 
specifications relevant to electronic prior authorization (85 FR 
82632):
     HL7[supreg] FHIR[supreg] Da Vinci Coverage Requirements 
Discovery (CRD) Implementation Guide.\8\
---------------------------------------------------------------------------

    \8\ For more information, see https://www.hl7.org/fhir/us/davinci-crd/.
---------------------------------------------------------------------------

     HL7[supreg] FHIR[supreg] Da Vinci Documentation Templates 
and Coverage Rules (DTR) Implementation Guide.\9\
---------------------------------------------------------------------------

    \9\ For more information, see https://hl7.org/fhir/us/davinci-dtr/.
---------------------------------------------------------------------------

     HL7[supreg] FHIR[supreg] Da Vinci Prior Authorization 
Support (PAS) Implementation Guide.\10\
---------------------------------------------------------------------------

    \10\ For more information, see https://hl7.org/fhir/us/davinci-pas/.
---------------------------------------------------------------------------

    These IGs were developed by the Da Vinci project, an initiative 
established in 2018 to help payers and providers positively impact 
clinical, quality, cost, and care management outcomes.\11\ The Da Vinci 
project is part of the HL7[supreg] FHIR[supreg] Accelerator 
Program.\12\ Under the Da Vinci project, industry stakeholders have 
facilitated the definition, design, and creation of use-case-specific 
implementation documentation and supporting materials based upon the 
HL7[supreg] FHIR[supreg] standard in order to address value-based care 
initiatives. Because the Da Vinci project is aligned with HL7[supreg] 
and its consensus-based approach to standards development, new and 
revised standards are easily and freely available for public use. While 
ONC proposed to adopt these IGs in the ONC Healthcare Operations 
Standards proposed rule in tandem with the proposed requirements for 
payers in the CMS Interoperability and Prior Authorization proposed 
rule (85 FR 82632), we are now seeking to understand the 
appropriateness of using these IGs to support functionality within 
certified health IT systems used by healthcare providers and other 
stakeholders.
---------------------------------------------------------------------------

    \11\ For more information, see https://www.hl7.org/about/davinci/.
    \12\ For more information, see https://www.hl7.org/documentcenter/public/pressreleases/HL7_PRESS_20190211.pdf.
---------------------------------------------------------------------------

    Below we offer a description of each IG and a discussion of key 
issues to help the public provide input.
Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide
    The purpose of this IG is to define a workflow whereby clinical IT 
systems can query coverage requirements from payer IT systems at the 
time treatment decisions are made. This ensures that clinicians and 
administrative staff can make informed decisions and meet the 
requirements of the patient's insurance coverage. Different insurance 
products may have varying requirements for prior authorization 
documentation. Providers who fail to adhere to payer requirements may 
not receive payer coverage for care provided or may cause a delay in 
needed care, which may result in increased out of pocket costs for 
patients, potential additional visits and changes in the preferred care 
plan, health risks for the patient, and increased burden for all 
parties involved.
    This IG utilizes the Clinical Decision Support (CDS) Hooks 
specification \13\ in order to: Establish triggers for querying payers 
for coverage requirements; define how payers publish services 
describing coverage requirements; define how clinical systems query 
payers for coverage requirements; and define how clinical systems 
present coverage requirements to users for clinical decision support. 
The CRD IG allows provider IT systems to query payer IT systems via CDS 
Hooks to determine if there are documentation requirements for a 
proposed medication, procedure, or other service. When a provider 
triggers a prior authorization-related CDS Hook within their IT system 
indicating that payer documentation requirements exist for a product or 
service, a CDS Hooks Card(s) is returned with information about the 
documentation requirements and options to read, accept a suggestion, or 
interact with an app to address those requirements.
---------------------------------------------------------------------------

    \13\ For more information, see https://cds-hooks.hl7.org/.
---------------------------------------------------------------------------

    The CRD IG extends the CDS Hooks specification to define additional 
hook resources, a hook configuration mechanism, additional prefetch 
capabilities, and additional response capabilities. In addition to the 
reliance of this IG on the nascent CDS Hooks specification, these 
extensions may change in the future, depending on how they are 
incorporated into the CDS Hooks specification, which may cause 
compatibility issues with future versions of the CRD IG.
    The information that may be shared using this IG includes:
     Updated coverage information.
     Alternative preferred/first-line/lower-cost services/
products.
     Documents, rules, forms, templates, and links to resources 
related to coverage.
     Updated clinical information for decision support.
     Indications of whether prior authorization is required.
Documentation Templates and Coverage Rules (DTR) Implementation Guide
    The purpose of the DTR IG is to ensure the completion of 
documentation needed to demonstrate medical necessity for a proposed 
medication, procedure, or other service. This IG specifies how payer 
coverage rules can be executed in a provider context to ensure that 
documentation requirements are met. A companion to the CRD IG, the DTR 
IG leverages the ability of CDS Hooks Cards to link to Substitutable 
Medical Applications, Reusable Technologies (SMART) on FHIR \14\ apps 
to launch and execute payer rules. The DTR IG describes the 
interactions between a SMART on FHIR app and the payer's IT system to 
retrieve the payer's documentation requirements, in the form of 
Clinical Quality Language (CQL) \15\ and a FHIR Questionnaire resource, 
for use by the provider and the provider's IT system. The provider's IT 
system communicates with the payer's IT system, which informs the 
provider's system of the documentation that needs to be completed using 
the CQL logic and the FHIR Questionnaire resource. To populate the FHIR 
QuestionnaireResponse, which are the results of the FHIR Questionnaire 
resource, the IG describes a process where the provider's IT system 
auto-populates as many fields as possible, then alerts the provider to 
any information gaps, which the provider can complete manually. The IG 
describes that all relevant information from these transactions is 
stored in the provider's IT system for future use, including to support 
subsequently providing the FHIR QuestionnaireResponse to the payer as

[[Page 3479]]

part of documentation for prior authorization.
---------------------------------------------------------------------------

    \14\ For more information, see https://docs.smarthealthit.org/
    \15\ For more information, see https://cql.hl7.org/
---------------------------------------------------------------------------

Da Vinci Prior Authorization Support (PAS) Implementation Guide
    The PAS IG uses the FHIR standard as the basis for (i) assembling 
the information necessary to substantiate clinical need for a 
particular treatment; and (ii) submitting the assembled information and 
prior authorization request to an intermediary before transmission to 
the intended recipient. Under the workflow specified in the PAS IG, to 
meet regulatory requirements for HIPAA standard transactions discussed 
above, the FHIR interface communicates with an intermediary 
functionality (such as a clearinghouse) that converts the FHIR requests 
to a HIPAA compliant X12 278 request transaction for submission to the 
payer. In some cases, the payer itself, if acting as the intermediary 
or clearinghouse, may convert the request to a HIPAA compliant X12 278 
transaction. Under the workflow specified in the PAS IG, the response 
from the payer would then flow back through the intermediary 
functionality using X12 and would be made available to the provider's 
health IT system using the FHIR standard. The response would indicate 
whether the payer approves (and for how long), denies (with a reason 
for denial), or requests more information about the prior authorization 
request. This IG also defines capabilities around the management of 
prior authorization requests, including checking on the status of a 
previously submitted request, revising a previously submitted request, 
and cancelling a request.
Discussion
    Based on public input to date, including comments received on the 
CMS Interoperability and Prior Authorization and ONC Healthcare 
Operations Standards proposed rules in December 2020, and our own 
review, we have identified a number of issues that may be relevant to 
the use of these IGs in certified health IT. These include concerns 
that the IGs lack maturity and have not yet undergone extensive testing 
in production and rely on other IGs and features in FHIR that are 
immature. In some cases, the available versions of the IGs propose 
changes and pre-adopt changes to dependent IGs, or request feedback on 
design considerations within the IGs that may impact compatibility 
between these versions and future versions. Additional issues regarding 
the PAS IG include concerns around the translation from FHIR to X12 
included as part of the specification. While enabling compliance with 
existing regulatory requirements, the translation approach may increase 
the number of transactions necessary for exchange as well as dependency 
on intermediaries. Issues regarding the DTR and CRD IGs include 
concerns that the detailed workflow described in the specification 
leverages CDS Hooks functionality, which has not yet been adopted in 
any certification criterion under the Certification Program. We welcome 
additional information about these IGs, especially given that a year 
has passed since we last heard from the public on this topic as part of 
the ONC Healthcare Operations Standards proposed rule.

f. Additional Approaches To Support Electronic Prior Authorization: 
Healthcare Attachments

    The implementation specifications described above represent 
important standards development collaborations between industry 
stakeholders. We believe these activities may present an important 
pathway to streamlining electronic prior authorization processes, as 
reflected in our proposal in the ONC Healthcare Operations Standards 
proposed rule. However, we understand that there are capabilities and 
standards currently supported by certified health IT products that may 
facilitate certain elements of prior authorization workflows. For 
instance, electronic exchange of healthcare attachments can be used to 
transmit clinical information in conjunction with an electronic 
administrative transaction to meet health plan requirements. ONC is 
aware of several standards initiatives within the last five years 
focused on advancing standards and functionality supporting clinical 
documents for a broad range of use cases, including for attachments 
within prior authorization and other administrative workflows.
    These initiatives include the HL7 implementation guide based on the 
Consolidated Clinical Document Architecture (C-CDA) Release, and HL7 
FHIR Documents:
     HL7 C-CDA R2 Attachment Implementation Guide: Exchange of 
C-CDA Based Documents, Release 1.\16\
---------------------------------------------------------------------------

    \16\ For more information, see https://www.hl7.org/documentcenter/public/standards/dstu/CDAR2_AIG_CCDA_EXCHANGE_R1_STU_2017AUG.pdf.
---------------------------------------------------------------------------

     HL7 FHIR Release 4, Section 3.3: FHIR Documents.\17\
---------------------------------------------------------------------------

    \17\ For more information, see https://www.hl7.org/fhir/documents.html.
---------------------------------------------------------------------------

    The HL7 C-CDA R2 Attachment Implementation Guide (CDA Attachments 
IG) defines the requirements for sending and receiving standards-based 
electronic attachments and incorporates certain administrative 
information into the document header. The C-CDA document templates are 
designed to be electronic versions of the most common types of paper 
document attachment information. ONC has adopted the C-CDA standard for 
use in the Certification Program in Sec.  170.205.
    An HL7 FHIR Release 4 FHIR Document (FHIR Documents) is a set of 
healthcare-related information that is assembled into a single package 
that provides a coherent statement, establishes its own context, and 
includes attribution with regard to who is making the statement. The 
FHIR Documents section of the base FHIR Release 4 standard (adopted by 
ONC in Sec.  170.215) specifies how FHIR resources can be used to build 
documents that represent a statement of healthcare information, 
including representing clinical observations and services as a cohesive 
composition. The resulting document is an immutable set of resources 
with a fixed presentation that can be used for a wide range of use 
cases, including administrative transactions.
Discussion
    Healthcare and health IT stakeholders have called for a 
standardized approach to electronic healthcare attachments, while 
emphasizing that solutions should align with advances in 
interoperability and that HHS policy should allow for innovation (for 
example, see public comments received by the HITAC in 2019,\18\ the 
NCVHS in 2018,\19\ 2020,\20\ and 2021,\21\ and the joint ICAD taskforce 
in 2020). Because of the ongoing advancement of health IT standards and 
functionality supporting clinical and care coordination workflows, 
there are several options available for interoperable exchange today, 
including both document-based exchange using the C-CDA base standard 
and exchange using standardized APIs using the FHIR base standard. This 
increase in interoperable options can support the combination of 
clinical and administrative data and allow for more timely and 
effective

[[Page 3480]]

approvals of prior authorization requests.
---------------------------------------------------------------------------

    \18\ See https://www.healthit.gov/sites/default/files/facas/2019-03-20_HITAC_Meeting_Notes.pdf.
    \19\ See https://ncvhs.hhs.gov/transcripts-minutes/transcript-standards-subcommittee-predictability-roadmap-hearing-day-one-december-12-2018/ and https://ncvhs.hhs.gov/transcripts-minutes/transcript-standards-subcommittee-predictability-roadmap-hearing-day-two-december-13-2018/.
    \20\ See https://ncvhs.hhs.gov/wp-content/uploads/2020/10/Public-Comments-CAQH-CORE-Operating-Rules-for-Federal-Adoption-August-2020r.pdf.
    \21\ See https://ncvhs.hhs.gov/wp-content/uploads/2021/08/Public-Comments-Standards-Subcommittee-Listening-Session-August-25-2021.pdf.
---------------------------------------------------------------------------

    We understand that stakeholders may also have concerns with these 
potential approaches, for instance, concerns related to lack of testing 
and production implementation of these approaches that are specific to 
the prior authorization use case, despite widespread use of the 
underlying standards for other purposes. Regarding the underlying 
standards for each approach, we understand that while the C-CDA has the 
benefit of being in widespread use, the more inflexible nature of the 
standard may increase the ongoing burden of maintenance and updates to 
the standard over time. FHIR solutions offer a more flexible and agile 
option over time, but there may be additional development and 
specification needed for their effective implementation. We welcome 
additional information about these standards and implementation 
specifications for this part of the prior authorization workflow.
    We also welcome further information on any other additional areas 
we should consider in supporting the exchange of healthcare attachments 
in prior authorization workflows. For example, we understand there is 
also ongoing work to create a FHIR-based IG for healthcare 
attachments.\22\ In addition, while the scope of this RFI is focused on 
prior authorization processes, we recognize that the systems used for 
this purpose may also support a wide range of administrative 
transactions and operations workflows and that healthcare attachments 
are used for other administrative and operations purposes such as 
claims processing. In the same way that aligned standards between 
administrative systems and clinical systems can optimize effectiveness, 
aligned standards across administrative use cases may also support 
efficiency. We therefore welcome public comment on the potential 
intersection with other administrative and operations processes that we 
should consider when exploring options for healthcare attachments, as 
well as comments on how to best harmonize these efforts. Finally, we 
welcome public comment on other standards initiatives, pilot projects, 
or health IT resources that we should explore to identify promising 
best practices, emerging standards, or innovative approaches to advance 
interoperable health IT for healthcare operations use cases.
---------------------------------------------------------------------------

    \22\ For more information, see https://build.fhir.org/ig/HL7/davinci-ecdx/.
---------------------------------------------------------------------------

II. Request for Comments

    ONC seeks public comments on whether to adopt additional standards, 
implementation specifications, and certification criteria as part of 
the Certification Program to ensure that technology is available to 
providers for the automated, electronic completion of prior 
authorization tasks. In addition to general comments on the issues 
presented above, we are seeking input on the following questions:
Certified Health IT Functionality
     Do the functional capabilities described above include all 
necessary functionality for certified Health IT Modules to successfully 
facilitate electronic prior authorization processes? Are there 
additional capabilities that should be included in certified Health IT 
Modules to address these needs? Should any of these functional 
capabilities not be included in certified Health IT Modules (please 
cite the reason they should be excluded) or should ONC focus on a more 
limited set of functional capabilities for certified Health IT Modules 
than those described above?
     Should ONC adopt a certification criterion for prior 
authorization that accounts for the full, HIPAA compliant workflow for 
prior authorization transactions including translation from FHIR to the 
X12 standard? Or should ONC adopt certification criteria that include 
only the workflows up to the point of translation? What ongoing 
challenges will stakeholders face if there is a need to translate 
between HIPAA-adopted standards and other standards that have only been 
adopted under the Certification Program used to support prior 
authorization transactions? How should HHS address alignment between 
standards adopted for HIPAA transactions and standards adopted under 
the Certification Program?
     If ONC were to propose to include these functional 
capabilities as part of the Certification Program, how should a new 
certification criterion (or multiple certification criteria) be 
structured, including technical requirements, attributed standards, and 
implementation specifications? ONC's experience adopting certification 
criteria suggests that, at times, combining related functions into a 
single Health IT Module is most appropriate, while in other cases, 
health IT functionalities are best represented by separate 
certification criteria, despite being functionally related. For 
instance, under a single criterion, different products and services in 
the market may be ``tightly coupled'' for the purposes of 
certification, even when they can be purchased and implemented 
separately. We seek the public's input on which functional capabilities 
for prior authorization should be tested and certified together as part 
of one certification criterion, and which capabilities should be 
separated into different certification criteria.
Implementation Specifications for Prior Authorization
     What is the current readiness of the three FHIR-based Da 
Vinci IGs described above for adoption as part of certification 
criteria for health IT? Given limited testing of these specifications 
to date, what would be a feasible timeline for use of these IGs in 
production for prior authorization transactions? What, if any, 
additional changes are needed for these IGs prior to adoption as part 
of certification criteria for health IT?
     If the existing IGs are not yet ready for adoption, should 
ONC still propose certification criteria? Should ONC consider proposing 
certification criteria incorporating the FHIR Release 4 base standard 
but delay adopting implementation specifications until a later date? 
What are the potential risks of this approach?
     If we were to adopt certification criteria referencing the 
base standard and then update those criteria to integrate 
implementation specifications in the future, how should these 
integrations be handled? When and how should the existing systems be 
replaced? All at once, or as a series of transitional steps?
     Do the Da Vinci IGs effectively support Federal and state 
legal requirements and/or health plan compliance requirements for 
clinical documentation, for example, signatures (or other indications 
of provider review and assent), record retention over long periods of 
time, and document security to ensure data integrity once stored?
     What alternative approaches to designing certification 
criteria should ONC explore that are not based on the three Da Vinci 
IGs described herein?
     Are there simplified approaches to the workflows described 
in the Da Vinci IGs that ONC should consider as alternative approaches 
to support electronic prior authorization?
     Are there new IGs which need to be developed in order to 
integrate with other workflows relevant to prior authorization? In 
particular, what IGs may still need to be developed in order to 
integrate with HIPAA administrative transaction standards?

[[Page 3481]]

Healthcare Attachment Standards
     Would the specifications within the CDA Attachments IG, if 
adopted as part of a certification criterion, support more effective 
exchange of healthcare attachments for prior authorization? Would any 
changes to the IG be needed, or would additional functionalities or 
standards be required for effective implementation of the CDA 
Attachments IG in certified health IT?
     Would the use of FHIR Documents, if adopted as part of a 
certification criterion, support more effective exchange of healthcare 
attachments? Are there any gaps or constraints that would need to be 
further specified, such as through an IG, in order for FHIR Documents 
to be effective for this use case when implemented in certified health 
IT? Would the adoption of a certification criterion for FHIR Documents 
support other administrative use cases beyond prior authorization?
     Given limited testing of these approaches to date, what 
would be a feasible timeline for use of the CDA Attachments IG or FHIR 
Documents in production for prior authorization transactions?
     Which of these approaches would better accommodate 
improvements over time to meet payer and provider needs? Should ONC 
consider adopting certification criteria referencing one approach over 
the other, or should ONC consider supporting both approaches within 
certified health IT?
     If the IGs developed by the Da Vinci Project, or an 
alternate set of IGs addressing the full scope of prior authorization 
workflows, are not yet ready for adoption in certified health IT, 
should ONC propose certification criteria to support healthcare 
attachments transactions for prior authorization alone?
     Healthcare attachments are used for a wide range of 
operations and administrative workflows beyond prior authorization. Are 
either of the standards discussed above commonly used in other 
administrative or operations transactions? Would there be a burden or 
benefit to using either, or both, standards in light of other 
administrative or operations workflows? Are there additional standards 
or implementation specifications ONC should consider that are in common 
use for healthcare attachments used in other administrative or 
operations workflows?
Impact on Patients
     How could potential changes to the Certification Program 
to better support prior authorization positively impact healthcare 
consumers?
     How could potential changes reduce the time for patients 
to receive needed healthcare services, reduce patient non-adherence, 
and/or lower out-of-pocket costs?
     Besides the provider to payer interactions discussed in 
this RFI, is there additional functionality that could be added to the 
Certification Program that would better support patients' participation 
in the prior authorization process?
Impact on Providers
     To what degree is availability of electronic prior 
authorization capabilities within certified health IT likely to reduce 
burden for healthcare providers who currently engage in prior 
authorization activities?
     To what degree are healthcare providers likely to use 
these new capabilities across their patient panels? Will additional 
incentives or requirements be needed to ensure healthcare providers 
effectively use these capabilities? What accompanying documentation or 
support would be needed to ensure that technology capabilities are 
implemented in ways that effectively improve clinical workflows?
     What estimates can providers share about the cost and time 
(in hours) associated with adopting and implementing electronic prior 
authorization functionality as part of care delivery processes?
Impact on Developers
     What estimates can health IT developers share about the 
cost and time (in hours) of developing electronic prior authorization 
functionality within certified health IT products?
     What factors would inform the burden for health IT 
developers to develop certified Health IT Modules for electronic prior 
authorization based on the three Da Vinci IGs described above?
     What would be the burden on health IT developers for prior 
authorization certification criteria referencing the base FHIR standard 
if there were not yet specific IGs adopted as well? How would 
potentially moving to criteria with use case specific IGs over time 
impact development burden? Would such a staged approach be detrimental 
or beneficial to the long-term development timeline and burden for 
health IT developers seeking to support electronic prior authorization?
Payer Implementation
     How could the Certification Program support the technology 
needs of healthcare payers in implementing electronic prior 
authorization? Should ONC consider payer workflows in the development 
of certification criteria to support the potential use of certified 
Health IT Modules by healthcare payers? Would the availability of 
certified Health IT Modules supporting these workflows reduce the 
burden for healthcare payers of engaging with healthcare providers in 
prior authorization processes?
     To what extent would healthcare payers be likely to use 
these certified Health IT Modules if they were available? To what 
extent are health IT developers likely to seek certification for Health 
IT Modules supporting payer workflows if these certification criteria 
were available?

    Dated: January 19, 2022.
Xavier Becerra,
Secretary, Department of Health and Human Services.
[FR Doc. 2022-01309 Filed 1-21-22; 8:45 am]
BILLING CODE 4150-45-P