Stream: Da Vinci PAS
Topic: Transaction History
Sean O'Quinn (Nov 29 2021 at 19:00):
In the PAS workflow where a prior auth is submitted, does the PAS IG or FHIR support a "transaction history" that shows the state of the prior authorization when it was initially submitted and for subsequent submissions (if needed)? Inherently a user managing the prior authorization will want to see a snapshot or history of the prior authorization as it goes back and forth. Should there be a way for a FHIR consumer to do some sort of GET to see the state of the request as it was sent?
Lloyd McKenzie (Nov 29 2021 at 23:28):
PAS can't do anything that X12 can't do. Is this an X12 capability?
Sean O'Quinn (Nov 30 2021 at 02:12):
Not necessarily, but couldnt one make the argument that the ClaimResponse resource is a single response that shouldnt be updated? That its a snapshot?
That being said, there isnt a ClaimRequest resource unless we are considering the Claim resource the request, but that seems a little weird to have Request and Response resource, but no resource to interact with the prior authorization outside the request and response
Lloyd McKenzie (Nov 30 2021 at 02:23):
In principle, the "ClaimResponse" is actually the "Authorization". (I've long argued that it should be called something like 'ClaimEvaluation' or 'ClaimAdjudication' to remove the premise that it will always be created in response to a Claim - because that's not always true.) The key point here is that PAS is a façade over the X12 capabilities. The FHIR resources can't expose anything that the payer doesn't expose over X12 (regardless of what resources we use).
Sean O'Quinn (Nov 30 2021 at 03:59):
Then what does the Claim Resource represent?
Sean O'Quinn (Nov 30 2021 at 04:01):
I dont understand why Prior Auths cant be a single resource like Patient, and I dont understand why its shared with Claim.
"... the 'ClaimResponse' is actually the 'Authorization'..." doesnt really match with the idea of Claim and ClaimResponse base resources does it? If its sharing the resource shouldnt it behave the same as the base resource?
Lloyd McKenzie (Nov 30 2021 at 14:29):
It's sort of like ServiceRequest and Procedure. Claim is the 'request' resource - it asks for something to be done (process a claim, process a prior authorization request). ClaimResponse is the result of that processing - the adjudication of the claim or of the prior authorization request. There can be multiple ClaimResponse instances for a single claim. First, a fully pended response, then a partially adjudicated response, then a fully adjudicated response - even if the Claim never changes.
Sean O'Quinn (Nov 30 2021 at 19:58):
So then what would a consumer interact with to get the Claim request ready? If you are saying the Claim resource really is "ClaimRequest", then there needs to be another resource for a consumer to interact with. In a UI world you do other work to prep the authorization before you send it off.
Lloyd McKenzie (Nov 30 2021 at 21:54):
A Claim is essentially an "AdjudicationRequest". I don't understand why there would need to be another resource for a consumer to interact with - I'm also not exactly sure who you consider a 'consumer' to be. You have a resource that defines what you want adjudicated (for claims processing, prior authorization or pre-determination) and a resource that represents the adjudication process (be it in progress or final). What else is required?
Sean O'Quinn (Nov 30 2021 at 22:55):
Lets think of it this way... You have to build a Claim before you submit it, but if you have the Claim resource as the "Request" then how would a consumer of the resource know when they are working on a Claim that hasnt been submitted and when they are working on a Claim that has already been submitted?
IMO the Bundle with all the resources is the "request"... not the Claim resource
Lloyd McKenzie (Dec 01 2021 at 02:36):
The same way you work on a referral or prescription or any other request resource. You create it with a status of 'draft' on your local machine and edit as you see fit. Eventually you set the status to 'active' when it's ready to go. Then you use one of the various FHIR workflow mechanisms to ask a payer to adjudicate it. For most Request resources, this would typically happen using Task. For most of the financial resources, the pattern is to use a $submit operation (generally because payers don't typically expose their data over RESTful interfaces or have an ability to query data sitting in clinical systems).
Last updated: Apr 12 2022 at 19:14 UTC
