CMS-0057-F rule requires payers to display metrics related to the prior authorisation process in a public-facing dashboard. The metrics include the number of approved/denied prior authorisations. How can we identify whether a prior auth request is approved or denied using the fields in the ClaimResponse? I found out the following when I was looking into this. ClaimResponse.outcome - this only gives the processing status of the claim. If the outcome is"complete", this means the claim processing is completed, but we cannot determine whether it is approved. ClaimResponse.reviewAction - this contains in each item of the ClaimResponse under adjudication. The terminology binding referred to in the PAS specification is X12278ReviewDecisionReasonCode . The codes like A1, A2, A3 and A4 can be used to indicate the approval and D1 can be used to indicate denial. I assume we can use a combination of both above fields to determine the approval/denial of a claim. Is my understanding correct? For eg, the outcome must be "complete" and the item should be approved). Also, When there are multiple items in the claim, should all the items be approved to consider the whole claim as approved? How should this be handled when only a subset of items are approved, and others are denied? I'm asking this because in the CMS-0057-F regulation, the metrics are required for the whole prior authorisation claim. Additionally, the PAS specification defines the above code system (X12278ReviewDecisionReasonCode) to represent the status of an item in the reviewActionCode. How does the systems that doesn't support X12 handle this? In that case, is there any other code system that they can use?

I'll answer the last question first - it's not possible to comply with PAS without having a license to use the X12 standard. Where there's a required or extensible binding to X12 codes, you'd be non-conformant to not use them. Given that payers and EHRs must all have X12 licenses to manage claim submissions (which by law need to be X12), this is not seen as an unreasonable imposition. If you want to be an intermediary that supports prior auth and not claims, you'll still need an X12 license. Most payers will manage metric calculation using their internal data, as they'll have to evaluate against all authorization requests they receive - PAS, portal, paper, NCPDP, etc. A solution that only evaluates metrics based on PAS won't be sufficient unless the payer is in the extremely unusual situation of having 100% of their auth requests coming in through PAS (or CRD or DTR if they do unsolicited auths) in the first year. Your question about how partial approvals is a good one - that's a question that'll need to be asked of the regulators themselves. I'll see whether Da Vinci might be able to raise this question on behalf of implementers.

Thanks for your reply. Please do raise the query regarding the partial approvals to the regulators. Let me add some more to that query. The items field in the PAS Claim Response is also optional. Means there can be claim responses with no items. The concern of how the approval/denial can be determined for this kind of claim response should also be addressed.

Again, stats aren't expected to be produced based on the PAS responses, they're expected to be generated based on the payers internal data.

That was not intended for stats.

@Jean Duteau will need to speak to what circumstances item can be omitted in the response.

While it is possible for a ClaimResponse to not have any items, that would only be in the case where there was an error in processing the incoming Claim. If the Claim was processed and is either complete or pended, then the ClaimResponse will have items in it.