Da Vinci Prior Authorization Support (PAS) FHIR IG
2.1.0-preview - STU 2 United States of America flag

This page is part of the Da Vinci Prior Authorization Support (PAS) FHIR IG (v2.1.0-preview: QA Preview) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 2.0.1. For a full list of available versions, see the Directory of published versions

PAS Metrics

Page standards status: Informative

Previous Page - ePA Coordinator Workflow

Overview

This Implementation Guide (IG) is one of 4 HL7 Da Vinci IGs that are designed to address the challenges of automating the exchange of information between a provider and the responsible payer to determine coverage of services, items, and referrals. In particular, these IGs standardize the exchange of information required to automate the Prior Authorization (PA) process. The specific IG are:

  1. Coverage Requirements Discovery (CRD)
  2. Documentation Templates and Rules (DTR)
  3. Prior Authorization Support (PAS) (this guide)
  4. Clinical Documentation Exchange (CDex)

Each guide supports a specific set of functions and exchanges required to determine payer coverage for specific services, items, and referrals.

To maximize the value of these IGs, it is imperative that each IG is integrated into clinical workflow at the appropriate point and all of the exchanges required by each IG are fully supported by all of the participants (providers, intermediaries, and payers).

Each of these IGs recommends a set of metrics that SHOULD or MAY be collected by their respective implementations to facilitate the evaluation of adoption, functionality, processes, and improved outcomes. While there is currently no requirement to report on these metrics, it is reasonable to believe that in the future interested entities (providers, payers, regulators, quality organizations, certification agencies, states, etc.) will ask for these metrics to evaluate the ongoing automation of the supported processes / exchanges. While this guide will not require these metrics to be captured in this release, the authors strongly suggest each implementation should do so with the expectation that collection and dissemination of these metrics may become a requirement (SHALL) in future version of these IGs.

The table below defines a set of measures with a short name, purpose, conformance, stakeholder, and collection/calculation instructions that represent what the project group designing this IG felt would be both reasonably collectable and useful in evaluating implementations of this IG. These measures are based on the metric data model logical model also published in this IG.

Suggested Metrics

The following table defines a set of metrics with a purpose, type, and stakeholder (based on the Metric Data model below).

Nbr Metric Metric Type Stakeholder Calculation Example
1 Volume of PAS submissions (as 278 and line items) Adoption Provider / Payer / Intermediary For 278 volume: PASMetricData.response.exists.count() For service items: PASMetricData.itemDetail.exists.count()
2 Volume of PAS Updates, Cancels, Queries Adoption Process Provider / Payer / Intermediary For Cancel volume: PASMetricData.exists.where(exchange.type = "cancel").count()
3 Volume of queries by other than ordering provider Process Provider / Payer / Intermediary For Query volume: PASMetricData.exists.where(exchange.type = "query").count()
4 % of PAS submissions returning an error (by type and payer) Process Provider (all errors) / Payer (subset) / Intermediary (subset) PASMetricData.where(httResponse != 200).count() For percent: divide volume above by PASMetricData.exists.count() and express as a percentage
5 % of PAS submissions returning a final result on initial submission (any item and all items) Process Outcome Provider / Payer Number of final : PASMetricData.where(exchange.type = "initial" and itemDetail.result != "pended").count() Divide volume above by: PASMetricData.where(exchange.type = " initial" and itemDetail.exists).count() and express as a percentage
6 Volume of line items that have an initial PEND and number of PENDS that were resolved and (more complex) average time to resolve each PEND Process Outcome Provider / Payer Number of initial PEND: PASMetricData.where(exchange.type = "initial" and itemDetail.result = "pended").count()
7 Total time from initial submission until final PA result for all line items Process Provider / Payer PASMetricData.where(ItemDetial.result != "pended") (finalResponseTime - InitialSubmissionTime)
8 All of the above by payer / provider (depending on metric) and over time Segmentation Provider / Payer Segmentation based on time and PASMetricData.source and (PASMetricData.payerID or PASMetricData.groupID)
9 Outstanding PAS requests Operation Dashboard Provider / Intermediary PASMetricData.exists.where(itemDetail.result = "pended").count()
10 Aging of PENDED requests Operation Dashboard Provider / Intermediary for each of the above items (current time - initialSubmissionTime)

Metric Data Model

In the interest of enabling such evaluation processes, this guide has defined a logical PAS Metric model that describes the data elements most likely to be relevant for such evaluation.

This model is NOT a FHIR data structure for information exchange. Instead, it is a logical model that describes the types of data that should be available and any constraints on the data (e.g. cardinality, terminology) that should be captured by PAS implementers to support the evaluation of metrics. Measures can then be defined in a standardized way based on these measures.

PAS implementers SHOULD store information for each PAS call in a manner that would allow them to respond to measures based on this logical model.

Next Page - Downloads