Standards will Make or Break Efforts Toward ePA

By Janet Campbell (Epic), EHRA Public Policy Leadership Workgroup Vice Chair

This is part two in a four-part series examining the need for ePA, the barriers presented by the current environment, necessary capabilities, and functionality, and the EHR Association’s policy recommendations. Part one can be read here.

Streamlining the electronic prior authorization (ePA) process will require significant coordination and standardization across multiple domains within individual healthcare organizations, across dozens of health plans covering their patients, and across the health IT tools in use by every participant in the process.

Progress is being made by various stakeholders in terms of standards development. Notably, the Coverage Requirements Determination (CRD), Documentation Templates and Rules (DTR), and the Prior Authorization Support (PAS) implementation guides – all a part of the Da Vinci Project’s efforts to understand functional requirements, build consensus on a technical approach, pilot, and iterate – have resulted in significant progress toward the enablement of highly automated prior authorization workflows.

However, adoption will be impeded by insufficient maturity of those standards to enable a robust, testable certification program. Current implementation guides are too coarse and are written at a level of abstraction that doesn’t fully support the ePA workflow across multiple users and their HIT tools. Specifically, standards and implementation guides are needed that are better suited for the variety of interactions – e.g., triggering ePA workflow with an intermediary, receiving notifications from that intermediary, access to supporting information, and status updates – that need to be in place for ePA interactions with each of the provider and payer HIT environments.

Standards and Certification Processes

The standards challenge is not limited to the implementation guide. The monolithic USCDI is also problematic for its lack of agility when it comes to allocating the relevant subset of USCDI data for specific use cases considering that HIT would have to be certified to supporting all USCDI, even though ePA would only need some of the USCDI data (e.g., not all demographics, assessment and plan of treatment, care team members, or goals). Not all systems that will exchange data as a part of the ePA process will have any reason to record or exchange the entire breadth of USCDI – for example, a payer’s system might not have reason to capture a patient’s unique device identifier and shouldn’t be expected to do so. As such, it’s better to establish a process for certification that does not require full USCDI support for a system to be certified for its role in the ePA workflow.

The current all-or-nothing approach to certification will not work with ePA because the electronic systems participating in the ePA process are as unique as the stakeholders who use them.

The current all-or-nothing approach to certification will not work with ePA because the electronic systems participating in the ePA process are as unique as the stakeholders who use them. While we endorse the creation of  a comprehensive list of certification capabilities, systems should be able to achieve certification on a subset of that list that is appropriate for their setting. For example, provider organizations have widely varying approaches to the adoption and deployment of health IT systems. Some use a single, integrated health IT solution that encompasses all the functionality required to enable prior authorization, but others – typically larger provider organizations – may have capabilities for prior authorization and financial management distributed across multiple health IT solutions from different vendors, mirroring a more distributed or federated approach to prior authorization overall.

Requiring certification to a complete prior authorization workflow for provider-focused health IT is premature, considering both the variety of practical and valid configurations of health IT and the absence of clearly defined, more granular interaction sets within the respective guides. A phased and focused approach should be considered to advance capabilities across the relevant health IT.

Healthcare providers should have the flexibility to choose which health IT solutions they use to meet the individual functional needs in the prior authorization workflow.  Such flexibility would also give health IT developers the ability to learn and choose which components of the prior authorization workflow are reasonable to support within their systems, without being forced to expand to offer additional capabilities in new markets that are otherwise not needed.

Recommendations

The EHR Association urges ONC not to allocate all provider-side interactions to just one health IT solution, but rather recognize the need for flexibility. At the same time, we recognize that it is important for providers to have certainty that their full health IT suite supports the entire prior authorization workflow. As such, we recommend ONC work first with CMS to focus adoption and certification of CRD, DTR, and PAS implementation guides on the payer side and establish a clear implementation standard for any interactions with the payers supporting prior authorization.

We also discourage the establishment of certification criteria for provider-focused health IT until there is clarity on how specific functional needs supported by the implementation guides map to the various systems in use at healthcare organizations to support prior authorization, including certified EHRs, non-certified health IT, and SMART on FHIR apps. 

The presence of standardized payer APIs for prior authorizations will encourage health IT developers to determine how to best adopt the same standards as payers, but only for those interactions that their health IT needs to support. ONC should make test harnesses available for the respective interactions that can be exercised individually.

Health IT certification criteria can ultimately be established based on the matured and evolved interaction distributions across health IT, with the typical interaction sets documented clearly within each of the CRD, DTR, and PAS implementation guides. Until then, any all-or-nothing requirement would be premature and detrimental to progress toward a mutually beneficial ePA.

Along with Campbell, contributing authors to this blog series are EHRA Chair Hans Buitendijk (Oracle Cerner), EHRA Co-chair David Bucciferro (Foothold Technology), EHRA Public Policy Leadership Workgroup Chair Leigh Burchell (Altera Digital Health). 

Leave a comment

Share your thoughts on this topic!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Categories

  • Follow EHRA on Twitter

  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 175 other followers
  • Contact Us

    Kasey Nicholoff
    staff @ ehra.org

    Amanda Patanow
    Communications and Media
    ehracomms @ npccs.com
%d bloggers like this: