Details
-
Change Request
-
Resolution: Persuasive
-
Medium
-
US Da Vinci PAS (FHIR)
-
current
-
Financial Mgmt
-
Formal Specification
-
-
Clarification
-
Non-substantive
Description
Following up on some concerns about ticket resolutions while withdrawing negative votes, on https://jira.hl7.org/browse/FHIR-36152:
This one was about trying to standardize the behavior of when an EHR is expected to send an update vs send a new auth request, given that the requirements will vary between payers. The resolution updated https://build.fhir.org/ig/HL7/davinci-pas/specification.html#updating-authorization-requests to say that an update should be attempted first, and if rejected then a new auth request should be made- however as far as I can tell nothing defines what that rejection looks like so the behavior is still ambiguous.
I would want to see something in that section making it clear, such as: “An example of this type of rejection would be ClaimResponse.error with code 33 – Input Errors, an error.followupAction of N – Resubmission Not Allowed, an error.errorElement of 2000E, and a ClaimResponse.processNote[0] containing ‘Updates are not allowed. A new auth request must be submitted.’”
The pattern isn’t ideal but that’s all I’m coming up with given that we’re limited to the 278R response. Whatever way we want to handle it, it’s important to have some common expectations defined of how this part will work.