Da Vinci Prior Authorization Support (PAS) FHIR IG
2.2.0-ballot - STU 2.2 - Ballot

Da Vinci Prior Authorization Support (PAS) FHIR IG, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.2.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-pas/ and changes regularly. See the Directory of published versions

## PAS Metrics

Page standards status: Informative

### 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.