Stream: implementers
Topic: X12 278 ClaimResponse information
Jean Duteau (May 30 2019 at 17:19):
@Paul Knapp I'm looking at the X12 278 response and there is a bunch of information repeated from the requesting claim that does not map to the FHIR ClaimResponse resource. For much of this information, I guess it makes sense because it is claim information that was used to make the medical decision - and that is why X12 included it in the response. Since the FHIR ClaimResponse can just link to the requesting claim, I don't think we need this information in the ClaimResponse, but then there is no way to indicate back to the requester that "I used this information in making my decision".
Lloyd McKenzie (May 30 2019 at 17:53):
Part of the challenge here is that it's not going to be a mirror of the submitted claim. It may exclude some information that was submitted with the claim (that the payer decided wasn't relevant to the adjudication) and it may include additional information that was provided supplementally via separate transactions that was deemed relevant. This feels to me similar to the "placer order" / "filler order" situation we have in other aspects of healthcare where the filling system (in this case the payer) creates their own view of the request that is both consistent with but differs somewhat from what was submitted to reflect what it is they actually are intending to (and eventually do) execute against.
Lloyd McKenzie (May 30 2019 at 17:54):
However, I don't see the structures that allow you to have two separate Claim business objects (provider's view vs. payer's view), nor any mechanism to link them. Also @MaryKay McDaniel
Jean Duteau (May 30 2019 at 17:54):
Yes, I agree with that.
Paul Knapp (May 31 2019 at 14:22):
@Jean Duteau the X12 835 is the Claim Response (remittance advice), 278 is the Prior Auth request/ response.
If the information in the response is simply a copy from the claim then there is no need to include it in the response. The payor would/could/should be using/considering all of the information in the claim plus their history files to inform their adjudication of the claim.
If someone was later mapping the ClaimResponse back to a 835 they would need access to the Claim to obtain the previously discarded information to faithfully render the 835 - I know that isn't actually part of your use case.
Paul Knapp (May 31 2019 at 14:38):
@Jean Duteau What they execute against is what was submitted on the Claim, and supporting information supports but does not redefine the claim. For example, if a provider submits a product/service code A12345 for the amount of $1000 then in their adjudication the payor will indicate: submitted=$1000; eligible=800.00 (the allowed amount at which the payor values the service); eligibilepercent=80% (the percentage, if expressed that way that the beneficiary's policy will pay for this type of service); benefit=640 (the amount the insurer is due to pay under the policy).
Now if supporting information had not substantiated the claim above the eligiblepercentage would be 0 and the benefit would be 0 and typically explanatory text or a reason would be provided.
Similarly if the patients coverage had a maximum annual payable of 2000 and 1500 had previously been paid by the insurer as benefits then the benefit amount would be 500 with the reason that the coverage had been exhausted.
Another situation is where the provider submits a bundled product or service code, for example for $1000 where the insurer views this as two separate codes in which case the the claim response would have the eligible=0 and 2 addItems would be created each pointing back at the submitted item with (for example) one with a submitted=$600, eligible=$600, eligibilepercent=80%, benefit=$480 and the other with submitted=$400, eligible=$400, eligibilepercent=80%, benefit=$320.
Paul Knapp (May 31 2019 at 15:00):
With regard to the comparison to a Placer and a Filler the comparison doesn't work well as a direct compare to the Provide and Payor in Claim relationship as the Provider is simply telling the Payor what costs were incurred on the patients behalf and requesting that the Payor consider that under their insurance policy with the subscriber under which the patient is covered. The insurer can't alter what was actually performed, they can only answer the question and the Provider can only deal with the answer provided in the context of the question asked.
Lloyd McKenzie (May 31 2019 at 15:03):
The prior authorization response includes a subset of the information that was in the claim (plus potentially more). It nominally reflects the set of information that was included as part of the adjudication process. As such, it does need to come back and because it's not the same as what was on the claim, it can't be a straight copy of the claim data. This is all about the supporting information, not the actual $$ requested
Paul Knapp (May 31 2019 at 15:05):
Do you mean information contained in the prior auth request as a claim won't have happened yet? Can you provide an example?
Lloyd McKenzie (May 31 2019 at 15:09):
My understanding is that when a prior authorization is submitted, a certain amount of supporting information is submitted in support of the claim. Additional supporting information may be submitted as part of supplementary transactions - and the payor may already have other data from previously submitted claims/other sources. When a prior authorization decision is returned, it is accompanied by the supporting information the payer actually used in evaluating the request - which may be both less than and more than what was submitted with the original prior authorization request. Essentially it's the "supporting information" for the authorization decision. The question is: how do we communicate that information?
Lloyd McKenzie (May 31 2019 at 15:10):
(As with the prior authorization request, the supporting information can be tied to particular line items it's deemed to be relevant to.)
Paul Knapp (May 31 2019 at 15:16):
This is US-centric, and from my recollection of Mary Kays comments I expect not actually in use to any material degree, but I will check with her on the business intent and the expected usage so we can support if needed.
Last updated: Apr 12 2022 at 19:14 UTC
