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

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

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 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® 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 ( printed page 3478)
• Effectively capture and persist digital signatures (or other indications of provider review and assent), enable data integrity of documentation over time, and support other features necessary to meet payer administrative requirements associated with prior authorization transactions.

We invite further comment on whether these are the appropriate minimum capabilities needed for certified health IT systems to successfully interact with payer systems to complete key electronic prior authorization activities.

e. Implementation Specifications To Support Electronic Prior Authorization Capabilities

As noted above, in the ONC Healthcare Operations Standards proposed rule ONC proposed to adopt, on behalf of HHS, three implementation specifications relevant to electronic prior authorization (85 FR 82632):

• HL7® 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 use-case-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 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 ( printed page 3479) 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 ( printed page 3480) 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 HIPAA-adopted standards and other standards that have only been adopted under the Certification Program used to support prior authorization transactions? How should HHS address alignment between standards adopted for HIPAA transactions and standards adopted under the Certification Program?
• If ONC were to propose to include these functional capabilities as part of the Certification Program, how should a new certification criterion (or multiple certification criteria) be structured, including technical requirements, attributed standards, and implementation specifications? ONC's experience adopting certification criteria suggests that, at times, combining related functions into a single Health IT Module is most appropriate, while in other cases, health IT functionalities are best represented by separate certification criteria, despite being functionally related. For instance, under a single criterion, different products and services in the market may be “tightly coupled” for the purposes of certification, even when they can be purchased and implemented separately. We seek the public's input on which functional capabilities for prior authorization should be tested and certified together as part of one certification criterion, and which capabilities should be separated into different certification criteria.

Implementation Specifications for Prior Authorization

• What is the current readiness of the three FHIR-based Da Vinci IGs described above for adoption as part of certification criteria for health IT? Given limited testing of these specifications to date, what would be a feasible timeline for use of these IGs in production for prior authorization transactions? What, if any, additional changes are needed for these IGs prior to adoption as part of certification criteria for health IT?
• If the existing IGs are not yet ready for adoption, should ONC still propose certification criteria? Should ONC consider proposing certification criteria incorporating the FHIR Release 4 base standard but delay adopting implementation specifications until a later date? What are the potential risks of this approach?
• If we were to adopt certification criteria referencing the base standard and then update those criteria to integrate implementation specifications in the future, how should these integrations be handled? When and how should the existing systems be replaced? All at once, or as a series of transitional steps?
• Do the Da Vinci IGs effectively support Federal and state legal requirements and/or health plan compliance requirements for clinical documentation, for example, signatures (or other indications of provider review and assent), record retention over long periods of time, and document security to ensure data integrity once stored?
• What alternative approaches to designing certification criteria should ONC explore that are not based on the three Da Vinci IGs described herein?
• Are there simplified approaches to the workflows described in the Da Vinci IGs that ONC should consider as alternative approaches to support electronic prior authorization?
• Are there new IGs which need to be developed in order to integrate with other workflows relevant to prior authorization? In particular, what IGs may still need to be developed in order to integrate with HIPAA administrative transaction standards? ( printed page 3481)

Healthcare Attachment Standards

• Would the specifications within the CDA Attachments IG, if adopted as part of a certification criterion, support more effective exchange of healthcare attachments for prior authorization? Would any changes to the IG be needed, or would additional functionalities or standards be required for effective implementation of the CDA Attachments IG in certified health IT?
• Would the use of FHIR Documents, if adopted as part of a certification criterion, support more effective exchange of healthcare attachments? Are there any gaps or constraints that would need to be further specified, such as through an IG, in order for FHIR Documents to be effective for this use case when implemented in certified health IT? Would the adoption of a certification criterion for FHIR Documents support other administrative use cases beyond prior authorization?
• Given limited testing of these approaches to date, what would be a feasible timeline for use of the CDA Attachments IG or FHIR Documents in production for prior authorization transactions?
• Which of these approaches would better accommodate improvements over time to meet payer and provider needs? Should ONC consider adopting certification criteria referencing one approach over the other, or should ONC consider supporting both approaches within certified health IT?
• If the IGs developed by the Da Vinci Project, or an alternate set of IGs addressing the full scope of prior authorization workflows, are not yet ready for adoption in certified health IT, should ONC propose certification criteria to support healthcare attachments transactions for prior authorization alone?
• Healthcare attachments are used for a wide range of operations and administrative workflows beyond prior authorization. Are either of the standards discussed above commonly used in other administrative or operations transactions? Would there be a burden or benefit to using either, or both, standards in light of other administrative or operations workflows? Are there additional standards or implementation specifications ONC should consider that are in common use for healthcare attachments used in other administrative or operations workflows?

Impact on Patients

• How could potential changes to the Certification Program to better support prior authorization positively impact healthcare consumers?
• How could potential changes reduce the time for patients to receive needed healthcare services, reduce patient non-adherence, and/or lower out-of-pocket costs?
• Besides the provider to payer interactions discussed in this RFI, is there additional functionality that could be added to the Certification Program that would better support patients' participation in the prior authorization process?

Impact on Providers

• To what degree is availability of electronic prior authorization capabilities within certified health IT likely to reduce burden for healthcare providers who currently engage in prior authorization activities?
• To what degree are healthcare providers likely to use these new capabilities across their patient panels? Will additional incentives or requirements be needed to ensure healthcare providers effectively use these capabilities? What accompanying documentation or support would be needed to ensure that technology capabilities are implemented in ways that effectively improve clinical workflows?
• What estimates can providers share about the cost and time (in hours) associated with adopting and implementing electronic prior authorization functionality as part of care delivery processes?

Impact on Developers

• What estimates can health IT developers share about the cost and time (in hours) of developing electronic prior authorization functionality within certified health IT products?
• What factors would inform the burden for health IT developers to develop certified Health IT Modules for electronic prior authorization based on the three Da Vinci IGs described above?
• What would be the burden on health IT developers for prior authorization certification criteria referencing the base FHIR standard if there were not yet specific IGs adopted as well? How would potentially moving to criteria with use case specific IGs over time impact development burden? Would such a staged approach be detrimental or beneficial to the long-term development timeline and burden for health IT developers seeking to support electronic prior authorization?

Payer Implementation

• How could the Certification Program support the technology needs of healthcare payers in implementing electronic prior authorization? Should ONC consider payer workflows in the development of certification criteria to support the potential use of certified Health IT Modules by healthcare payers? Would the availability of certified Health IT Modules supporting these workflows reduce the burden for healthcare payers of engaging with healthcare providers in prior authorization processes?
• To what extent would healthcare payers be likely to use these certified Health IT Modules if they were available? To what extent are health IT developers likely to seek certification for Health IT Modules supporting payer workflows if these certification criteria were available?

87 FR 3475