Proposed Rule2022-01309
Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
January 24, 2022
Issuing agencies
Health and Human Services Department
Abstract
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.
Full Text
<html>
<head>
<title>Federal Register, Volume 87 Issue 15 (Monday, January 24, 2022)</title>
</head>
<body><pre>
[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 [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[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. <a href="http://www.regulations.gov">http://www.regulations.gov</a>.
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 <a href="http://www.regulations.gov">http://www.regulations.gov</a>.
Docket: For access to the docket to read background documents or
comments received, go to <a href="http://www.regulations.gov">http://www.regulations.gov</a> 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 <a href="https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf">https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf</a>.
---------------------------------------------------------------------------
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 <a href="https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program">https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program</a>.
---------------------------------------------------------------------------
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 <a href="https://www.caqh.org/sites/default/files/explorations/index/2020-caqh-index.pdf">https://www.caqh.org/sites/default/files/explorations/index/2020-caqh-index.pdf</a>.
---------------------------------------------------------------------------
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 <a href="https://www.caqh.org/core/operating-rules">https://www.caqh.org/core/operating-rules</a>.
---------------------------------------------------------------------------
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: <a href="https://www.healthit.gov/sites/default/files/page/2019-12/2019-10-16_ISP_TF_Final_Report_signed_508.pdf">https://www.healthit.gov/sites/default/files/page/2019-12/2019-10-16_ISP_TF_Final_Report_signed_508.pdf</a>.
---------------------------------------------------------------------------
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:
<a href="https://www.healthit.gov/sites/default/files/facas/ICAD_TF_FINAL_Report_HITAC_2020-11-06_0.pdf">https://www.healthit.gov/sites/default/files/facas/ICAD_TF_FINAL_Report_HITAC_2020-11-06_0.pdf</a>.
---------------------------------------------------------------------------
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:
<bullet> 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;
<bullet> Query a payer API for prior authorization requirements for
each item and service and identify in real time specific rules and
documentation requirements;
<bullet> Collect clinical and administrative documentation needed
to complete prior authorization documentation (electronic forms or
templates) from a health IT system;
<bullet> Electronically submit completed documentation for prior
authorization to a payer's API, along with supporting information;
<bullet> Receive a response from a payer regarding approval, denial
(including a reason for denial), or need for additional information;
<bullet> 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]]
<bullet> 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):
<bullet> HL7[supreg] FHIR[supreg] Da Vinci Coverage Requirements
Discovery (CRD) Implementation Guide.\8\
---------------------------------------------------------------------------
\8\ For more information, see <a href="http://www.hl7.org/fhir/us/davinci-crd/">http://www.hl7.org/fhir/us/davinci-crd/</a>.
---------------------------------------------------------------------------
<bullet> HL7[supreg] FHIR[supreg] Da Vinci Documentation Templates
and Coverage Rules (DTR) Implementation Guide.\9\
---------------------------------------------------------------------------
\9\ For more information, see <a href="http://hl7.org/fhir/us/davinci-dtr/">http://hl7.org/fhir/us/davinci-dtr/</a>.
---------------------------------------------------------------------------
<bullet> HL7[supreg] FHIR[supreg] Da Vinci Prior Authorization
Support (PAS) Implementation Guide.\10\
---------------------------------------------------------------------------
\10\ For more information, see <a href="http://hl7.org/fhir/us/davinci-pas/">http://hl7.org/fhir/us/davinci-pas/</a>.
---------------------------------------------------------------------------
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 <a href="https://www.hl7.org/about/davinci/">https://www.hl7.org/about/davinci/</a>.
\12\ For more information, see <a href="http://www.hl7.org/documentcenter/public/pressreleases/HL7_PRESS_20190211.pdf">http://www.hl7.org/documentcenter/public/pressreleases/HL7_PRESS_20190211.pdf</a>.
---------------------------------------------------------------------------
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 <a href="https://cds-hooks.hl7.org/">https://cds-hooks.hl7.org/</a>.
---------------------------------------------------------------------------
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:
<bullet> Updated coverage information.
<bullet> Alternative preferred/first-line/lower-cost services/
products.
<bullet> Documents, rules, forms, templates, and links to resources
related to coverage.
<bullet> Updated clinical information for decision support.
<bullet> 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 <a href="https://docs.smarthealthit.org/">https://docs.smarthealthit.org/</a>
\15\ For more information, see <a href="https://cql.hl7.org/">https://cql.hl7.org/</a>
---------------------------------------------------------------------------
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:
<bullet> HL7 C-CDA R2 Attachment Implementation Guide: Exchange of
C-CDA Based Documents, Release 1.\16\
---------------------------------------------------------------------------
\16\ For more information, see <a href="https://www.hl7.org/documentcenter/public/standards/dstu/CDAR2_AIG_CCDA_EXCHANGE_R1_STU_2017AUG.pdf">https://www.hl7.org/documentcenter/public/standards/dstu/CDAR2_AIG_CCDA_EXCHANGE_R1_STU_2017AUG.pdf</a>.
---------------------------------------------------------------------------
<bullet> HL7 FHIR Release 4, Section 3.3: FHIR Documents.\17\
---------------------------------------------------------------------------
\17\ For more information, see <a href="http://www.hl7.org/fhir/documents.html">http://www.hl7.org/fhir/documents.html</a>.
---------------------------------------------------------------------------
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 <a href="https://www.healthit.gov/sites/default/files/facas/2019-03-20_HITAC_Meeting_Notes.pdf">https://www.healthit.gov/sites/default/files/facas/2019-03-20_HITAC_Meeting_Notes.pdf</a>.
\19\ See <a href="https://ncvhs.hhs.gov/transcripts-minutes/transcript-standards-subcommittee-predictability-roadmap-hearing-day-one-december-12-2018/">https://ncvhs.hhs.gov/transcripts-minutes/transcript-standards-subcommittee-predictability-roadmap-hearing-day-one-december-12-2018/</a> and <a href="https://ncvhs.hhs.gov/transcripts-minutes/transcript-standards-subcommittee-predictability-roadmap-hearing-day-two-december-13-2018/">https://ncvhs.hhs.gov/transcripts-minutes/transcript-standards-subcommittee-predictability-roadmap-hearing-day-two-december-13-2018/</a>.
\20\ See <a href="https://ncvhs.hhs.gov/wp-content/uploads/2020/10/Public-Comments-CAQH-CORE-Operating-Rules-for-Federal-Adoption-August-2020r.pdf">https://ncvhs.hhs.gov/wp-content/uploads/2020/10/Public-Comments-CAQH-CORE-Operating-Rules-for-Federal-Adoption-August-2020r.pdf</a>.
\21\ See <a href="https://ncvhs.hhs.gov/wp-content/uploads/2021/08/Public-Comments-Standards-Subcommittee-Listening-Session-August-25-2021.pdf">https://ncvhs.hhs.gov/wp-content/uploads/2021/08/Public-Comments-Standards-Subcommittee-Listening-Session-August-25-2021.pdf</a>.
---------------------------------------------------------------------------
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 <a href="http://build.fhir.org/ig/HL7/davinci-ecdx/">http://build.fhir.org/ig/HL7/davinci-ecdx/</a>.
---------------------------------------------------------------------------
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
<bullet> 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?
<bullet> 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?
<bullet> 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
<bullet> 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?
<bullet> 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?
<bullet> 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?
<bullet> 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?
<bullet> What alternative approaches to designing certification
criteria should ONC explore that are not based on the three Da Vinci
IGs described herein?
<bullet> 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?
<bullet> 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
<bullet> 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?
<bullet> 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?
<bullet> 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?
<bullet> 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?
<bullet> 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?
<bullet> 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
<bullet> How could potential changes to the Certification Program
to better support prior authorization positively impact healthcare
consumers?
<bullet> 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?
<bullet> 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
<bullet> 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?
<bullet> 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?
<bullet> 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
<bullet> 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?
<bullet> 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?
<bullet> 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
<bullet> 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?
<bullet> 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
</pre></body>
</html>Indexed from Federal Register on January 24, 2022.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.