Federal Register / Vol. 87, No. 15 / Monday, January 24, 2022 / Proposed Rules 3475 

1For additional discussion of administrative 

burden associated with the prior authorization 

process, see the CMS Interoperability and Prior 

Authorization proposed rule at 85 FR 82606. 

2Office 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. 

information directly to the manager of the 

certification office, send it to the attention of 

the person identified in paragraph (k)(1) of 

this AD. Information may be emailed to: 9- 

ANM-LAACO-AMOC-Requests@faa.gov. 

(2) Before using any approved AMOC, 

notify your appropriate principal inspector, 

or lacking a principal inspector, the manager 

of the local flight standards district office/ 

certificate holding district office. 

(3) AMOCs approved for AD 2002–03–01 

(67 FR 6857, February 14, 2002) are approved 

as AMOCs for the corresponding provisions 

of this AD. 

(k) Related Information 

(1) For more information about this AD, 

contact Jeffrey Chang, Aviation Safety 

Engineer, Los Angeles ACO Branch, FAA, 

3960 Paramount Boulevard, Lakewood, CA 

90712; phone: (562) 627–5263; fax: (562) 

627–5210; email: jeffrey.chang@faa.gov. 

(2) For service information identified in 

this AD, contact Honeywell International, 

Inc., 111 South 34th Street, Phoenix, AZ 

85034; phone: (800) 601–3099; fax: (602) 365 

5577; website: https://

myaerospace.honeywell.com/wps/portal. You 

may view this referenced service information 

at the FAA, Airworthiness Products Section, 

Operational Safety Branch, 1200 District 

Avenue, Burlington, MA 01803. For 

information on the availability of this 

material at the FAA, call (817) 222–5110. 

Issued on January 18, 2022. 

Lance T. Gant, 

Director, Compliance & Airworthiness 

Division, Aircraft Certification Service. 

[FR Doc. 2022–01238 Filed 1–21–22; 8:45 am] 

BILLING CODE 4910–13–P 

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. http://

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 http://

www.regulations.gov. 

Docket: For access to the docket to 

read background documents or 

comments received, go to http://

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

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 


jspears on DSK121TN23PROD with PROPOSALS1
3476 Federal Register / Vol. 87, No. 15 / Monday, January 24, 2022 / Proposed Rules 

3For more information, see https://

www.healthit.gov/topic/certification-ehrs/aboutonc-health-it-certification-program. 

4See https://www.caqh.org/sites/default/files/ 

explorations/index/2020-caqh-index.pdf. 

5For more information on operating rules, see 

https://www.caqh.org/core/operating-rules. 

(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. 

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. 

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 

§ 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 

§ 170.404(b)(3), Certified API 

Developers (as defined in § 170.404(c)) 

with API technology previously 

certified to the criterion in 

§ 170.315(g)(8) must provide API 

technology certified to § 170.315(g)(10) 

to all API Information Sources (as 

defined in § 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 (§ 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

HIPAA also requires that HHS adopt 

operating rules for the HIPAA standard 

transactions. Operating rules are defined 

at § 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

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 


jspears on DSK121TN23PROD with PROPOSALS1
Federal Register / Vol. 87, No. 15 / Monday, January 24, 2022 / Proposed Rules 3477 

6HITAC 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. 

7Final 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. 

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. 

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® FHIR® Implementation Guides 

(IGs) for exchange of prior authorization 

information, including the HL7® FHIR®

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. 

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 FederallyFacilitated 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® FHIR®

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 


jspears on DSK121TN23PROD with PROPOSALS1
3478 Federal Register / Vol. 87, No. 15 / Monday, January 24, 2022 / Proposed Rules 

8For more information, see http://www.hl7.org/ 

fhir/us/davinci-crd/. 

9For more information, see http://hl7.org/fhir/us/ 

davinci-dtr/. 

10For more information, see http://hl7.org/fhir/ 

us/davinci-pas/. 

11For more information, see https://www.hl7.org/ 

about/davinci/. 

12For more information, see http://www.hl7.org/ 

documentcenter/public/pressreleases/HL7_PRESS_

20190211.pdf. 

13For more information, see https://cdshooks.hl7.org/. 

14For more information, see https://

docs.smarthealthit.org/ 

15For more information, see https://cql.hl7.org/ 

• 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® FHIR® Da Vinci Coverage

Requirements Discovery (CRD) 

Implementation Guide.8

• HL7® FHIR® Da Vinci

Documentation Templates and Coverage 

Rules (DTR) Implementation Guide.9

• HL7® FHIR® Da Vinci Prior

Authorization Support (PAS) 

Implementation Guide.10

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®

FHIR® Accelerator Program.12 Under 

the Da Vinci project, industry 

stakeholders have facilitated the 

definition, design, and creation of usecase-specific implementation 

documentation and supporting 

materials based upon the HL7® FHIR®

standard in order to address value-based 

care initiatives. Because the Da Vinci 

project is aligned with HL7® 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. 

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. 

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 FHIR14 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 autopopulates 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 


jspears on DSK121TN23PROD with PROPOSALS1
Federal Register / Vol. 87, No. 15 / Monday, January 24, 2022 / Proposed Rules 3479 

16For more information, see https://www.hl7.org/ 

documentcenter/public/standards/dstu/CDAR2_

AIG_CCDA_EXCHANGE_R1_STU_2017AUG.pdf. 

17For more information, see http://www.hl7.org/ 

fhir/documents.html. 

18See https://www.healthit.gov/sites/default/ 

files/facas/2019-03-20_HITAC_Meeting_Notes.pdf. 

19See https://ncvhs.hhs.gov/transcripts-minutes/ 

transcript-standards-subcommittee-predictabilityroadmap-hearing-day-one-december-12-2018/ and 

https://ncvhs.hhs.gov/transcripts-minutes/ 

transcript-standards-subcommittee-predictabilityroadmap-hearing-day-two-december-13-2018/. 

20See https://ncvhs.hhs.gov/wp-content/uploads/ 

2020/10/Public-Comments-CAQH-CORE-OperatingRules-for-Federal-Adoption-August-2020r.pdf. 

21See https://ncvhs.hhs.gov/wp-content/uploads/ 

2021/08/Public-Comments-StandardsSubcommittee-Listening-Session-August-25- 

2021.pdf. 

part of documentation for prior 

authorization. 

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

• HL7 FHIR Release 4, Section 3.3:

FHIR Documents.17

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 § 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 

§ 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 


jspears on DSK121TN23PROD with PROPOSALS1
3480 Federal Register / Vol. 87, No. 15 / Monday, January 24, 2022 / Proposed Rules 

22For more information, see http://build.fhir.org/ 

ig/HL7/davinci-ecdx/. 

approvals of prior authorization 

requests. 

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. 

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 HIPAAadopted 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? 


jspears on DSK121TN23PROD with PROPOSALS1
Federal Register / Vol. 87, No. 15 / Monday, January 24, 2022 / Proposed Rules 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 longterm 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 

FEDERAL COMMUNICATIONS 

COMMISSION 

47 CFR Part 25 

[IB Docket No. 21–456; RM–11855; FCC 21– 

123; FR ID 66659] 

Spectrum Sharing Rules for NonGeostationary Orbit, Fixed-Satellite 

Service Systems 

AGENCY: Federal Communications 

Commission. 

ACTION: Proposed rule. 

SUMMARY: The Federal Communications 

Commission (FCC or Commission) 

proposes to revise its rules governing 

spectrum sharing among nongeostationary satellite orbit, fixedsatellite service (NGSO FSS) systems. 

The FCC proposes that its existing 

spectrum sharing mechanism for NGSO 

FSS systems will be limited to those 

systems approved in the same 

processing round. The FCC also 

proposes to adopt a rule providing that 

later-round NGSO FSS systems will 

have to protect earlier-round systems, 

and invites comment on how to define 

such protection. In addition, the FCC 

seeks comment on whether to sunset, 

after a period of time, the interference 

protection afforded to an NGSO FSS 

system because of its processing round 

status. 

DATES: Comments are due on or before 

March 25, 2022; reply comments are 

due on or before April 25, 2022. 

ADDRESSES: You may submit comments, 

identified by IB Docket No. 21–456, by 

any of the following methods: 


jspears on DSK121TN23PROD with PROPOSALS1