Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria
Request for information
CFR Part: "45 CFR Part 170"
RIN Number: "RIN-0955-AA04"
Citation: "87 FR 3475"
Page Number: "3475"
"Proposed Rules"
Agency: "
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
ADDRESSES: You may submit comments, identified by RIN 0955-AA04, by any of the following methods (please do not submit duplicate comments). Because of staff and resource limitations, we cannot accept comments by facsimile (FAX) transmission.
Federal eRulemaking Portal: Follow the instructions for submitting comments. Attachments should be in Microsoft Word, Microsoft Excel, or Adobe PDF; however, we prefer Microsoft Word. http://www.regulations.gov.
Regular, Express, or Overnight Mail:
Hand Delivery or Courier:
Inspection of Public Comments: All comments received before the close of the comment period will be available for public inspection, including any personally identifiable or confidential business information that is included in a comment. Please do not include anything in your comment submission that you do not wish to share with the general public. Such information includes, but is not limited to: A person's social security number; date of birth; driver's license number; state identification number or foreign country equivalent; passport number; financial account number; credit or debit card number; any personal health information; or any business information that could be considered proprietary. We will post all comments that are received before the close of the comment period at http://www.regulations.gov.
Docket: For access to the docket to read background documents or comments received, go to http://www.regulations.gov or the
FOR FURTHER INFORMATION CONTACT:
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/
FOOTNOTE 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. END FOOTNOTE
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 (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.
FOOTNOTE 2
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.
FOOTNOTE 3 For more information, see https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program. END FOOTNOTE
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
In the 21st Century Cures Act final rule, ONC also finalized a new certification criterion at SEC170.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 SEC170.404(b)(3), Certified API Developers (as defined in SEC170.404(c)) with API technology previously certified to the criterion in SEC170.315(g)(8) must provide API technology certified to SEC170.315(g)(10) to all API Information Sources (as defined in SEC170.404(c)) deployed with certified API technology no later than
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 (SEC162.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
FOOTNOTE 4 See https://www.caqh.org/sites/default/files/explorations/index/2020-caqh-index.pdf. END FOOTNOTE
HIPAA also requires that HHS adopt operating rules for the HIPAA standard transactions. Operating rules are defined at SEC162.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."
FOOTNOTE 5 For more information on operating rules, see https://www.caqh.org/core/operating-rules. END FOOTNOTE
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.
FOOTNOTE 6 HITAC recommendations on priority target areas,
FOOTNOTE 7 Final Recommendations of the
In
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(R) FHIR(R) 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
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
* 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(R) FHIR(R) Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide. /8/
FOOTNOTE 8 For more information, see http://www.hl7.org/fhir/us/davinci-crd/. END FOOTNOTE
* HL7(R) FHIR(R) Da Vinci Documentation Templates and Coverage Rules (DTR) Implementation Guide. /9/
FOOTNOTE 9 For more information, see http://hl7.org/fhir/us/davinci-dtr/. END FOOTNOTE
* HL7(R) FHIR(R) Da Vinci Prior Authorization Support (PAS) Implementation Guide. /10/
FOOTNOTE 10 For more information, see http://hl7.org/fhir/us/davinci-pas/. END FOOTNOTE
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(R) FHIR(R) 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(R) FHIR(R) standard in order to address value-based care initiatives. Because the Da Vinci project is aligned with HL7(R) 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.
FOOTNOTE 11 For more information, see https://www.hl7.org/about/davinci/. END FOOTNOTE
FOOTNOTE 12 For more information, see http://www.hl7.org/documentcenter/public/pressreleases/HL7_PRESS_20190211.pdf. END FOOTNOTE
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
FOOTNOTE 13 For more information, see https://cds-hooks.hl7.org/. END FOOTNOTE
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 part of documentation for prior authorization.
FOOTNOTE 14 For more information, see https://docs.smarthealthit.org/ END FOOTNOTE
FOOTNOTE 15 For more information, see https://cql.hl7.org/ END FOOTNOTE
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
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/
FOOTNOTE 16 For more information, see https://www.hl7.org/documentcenter/public/standards/dstu/CDAR2_AIG_CCDA_EXCHANGE_R1_STU_2017AUG.pdf. END FOOTNOTE
* HL7 FHIR Release 4, Section 3.3: FHIR Documents. /17/
FOOTNOTE 17 For more information, see http://www.hl7.org/fhir/documents.html. END FOOTNOTE
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 SEC170.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 SEC170.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 approvals of prior authorization requests.
FOOTNOTE 18 See https://www.healthit.gov/sites/default/files/facas/2019-03-20_HITAC_Meeting_Notes.pdf. END FOOTNOTE
FOOTNOTE 19 See https://ncvhs.hhs.gov/transcripts-minutes/transcript-standards-subcommittee-predictability-roadmap-hearing-day-one-december-12-2018/ and https://ncvhs.hhs.gov/transcripts-minutes/transcript-standards-subcommittee-predictability-roadmap-hearing-day-two-december-13-2018/. END FOOTNOTE
FOOTNOTE 20 See https://ncvhs.hhs.gov/wp-content/uploads/2020/10/Public-Comments-CAQH-CORE-Operating-Rules-for-Federal-Adoption-August-2020r.pdf. END FOOTNOTE
FOOTNOTE 21 See https://ncvhs.hhs.gov/wp-content/uploads/2021/08/Public-Comments-Standards-Subcommittee-Listening-Session-August-25-2021.pdf. END FOOTNOTE
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
FOOTNOTE 22 For more information, see http://build.fhir.org/ig/HL7/davinci-ecdx/. END FOOTNOTE
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?
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
* 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
Impact on Providers
* To what degree is availability of electronic prior authorization capabilities within certified health IT likely to reduce burden for healthcare providers who currently engage in prior authorization activities?
* To what degree are healthcare providers likely to use these new capabilities across their patient panels? Will additional incentives or requirements be needed to ensure healthcare providers effectively use these capabilities? What accompanying documentation or support would be needed to ensure that technology capabilities are implemented in ways that effectively improve clinical workflows?
* What estimates can providers share about the cost and time (in hours) associated with adopting and implementing electronic prior authorization functionality as part of care delivery processes?
Impact on Developers
* What estimates can health IT developers share about the cost and time (in hours) of developing electronic prior authorization functionality within certified health IT products?
* What factors would inform the burden for health IT developers to develop certified Health IT Modules for electronic prior authorization based on the three Da Vinci IGs described above?
* What would be the burden on health IT developers for prior authorization certification criteria referencing the base FHIR standard if there were not yet specific IGs adopted as well? How would potentially moving to criteria with use case specific IGs over time impact development burden? Would such a staged approach be detrimental or beneficial to the long-term development timeline and burden for health IT developers seeking to support electronic prior authorization?
Payer Implementation
* How could the Certification Program support the technology needs of healthcare payers in implementing electronic prior authorization? Should ONC consider payer workflows in the development of certification criteria to support the potential use of certified Health IT Modules by healthcare payers? Would the availability of certified Health IT Modules supporting these workflows reduce the burden for healthcare payers of engaging with healthcare providers in prior authorization processes?
* To what extent would healthcare payers be likely to use these certified Health IT Modules if they were available? To what extent are health IT developers likely to seek certification for Health IT Modules supporting payer workflows if these certification criteria were available?
Dated:
Secretary,
[FR Doc. 2022-01309 Filed 1-21-22;
BILLING CODE 4150-45-P
Chubb Whitepaper Explores Factors Impacting Commercial Property Insurance Pricing
Butts County Magistrate Court
Advisor News
- Debt is limiting American retirement savings
- How starting a conversation with a stranger is like dating
- Why your clients might face higher taxes in retirement
- Year-end planning errors retirees should avoid
- Social cultivation: How to talk with wealthy prospects
More Advisor NewsAnnuity News
Health/Employee Benefits News
- Long-Term Care Insurance. Which Type Is Right For You?
- The Chamber in Hays, Kansas, announces new health insurance option for 2025
- GAPS strike tensions rise over threat to withhold teacher health insurance
- Tensions rise over loss of insurance
- Private health insurers in Colorado will need to cover abortion care beginning in January
More Health/Employee Benefits NewsLife Insurance News