FHIR Chat · ClaimResponse.Insurance.preAuthRef

Stream: implementers

Topic: ClaimResponse.Insurance.preAuthRef

Brian Foxx (Aug 03 2018 at 20:59):

If I want to send back a simple yes or no for pre-auth checks is this the field an object to use?

Lloyd McKenzie (Aug 03 2018 at 21:23):

@Paul Knapp

Paul Knapp (Aug 06 2018 at 10:55):

@Brian Foxx Hi Brian. Is this so that you can tell the provider whether a preauthorization is required (CoverageEligibility) or whether the indicated good/service is reimburseable. If that latter then a ClaimResponse.item[n].adjudication.category='eligible' and .amount= a non-zero amount (suggest the amount or limit you will pay).

The .insurance.preAuthRef is where you would put a reference number (alphanumeric) which the provider submits when they send in the Claim to refer back to your preauthorization. This is done with a business identifier as the preAuthReference number may be provided in multiple ways including via letter or over the phone.

Brian Foxx (Aug 06 2018 at 13:10):

@Paul Knapp Hi Paul. Thank you so much for your response. I'm just looking to return a yes or not status with a few more details regarding statuses that are dependent on other variables such as diagnosis, location, etc.

Paul Knapp (Aug 06 2018 at 13:13):

@Brian Foxx Then .category='eligibility' with .amount=0 would be a no, otherwise a yes, and the .reason can contain codes for why or .note can contain note text.

Brian Foxx (Aug 06 2018 at 13:24):

@Paul Knapp Ok so the object to use would be ClaimResponse.item[n].adjudication.category right?

Paul Knapp (Aug 06 2018 at 13:26):

@Brian Foxx Right, or the .adjudication.category of the item[n].detail[m] or .detail[m].subDetail[o]

Brian Foxx (Aug 06 2018 at 13:34):

@Paul Knapp Thank you so much

Fred Switzer (Aug 07 2018 at 21:30):

@Paul Knapp Hello Paul, I'd like to dive in to preAuthRef with a couple of questions:
1. Would this also be the correct field to use for the preauthorization use case (in which a Payer is using the ClaimResponse resource to reply to a preauthorization request sent in the form of a Claim), to allow the requesting system to refer back to this specific authorization when they next contact the Payer? In our system we usually refer to this concept as the Auth Number or Precert Number, depending on usage.
2. If a payer wishes to include multiple preauthorization numbers (one for each service they approve) how would they go about doing so, since this field is in the Insurance section and not the item, addItem, or even adjudication sections? I suspect that we would want multiple insurance sections with each sequence value corresponding to each item section's sequenceLinkId--Is this how you would expect it to work?

Paul Knapp (Aug 08 2018 at 09:43):

@Fred Switzer
1) Yes, ClaimResponse.insurance.preAuthRef contains the Auth Number (or they may supply the Auth number by letter or phone) which you would later send in ClaimResponse.insurance.preAuthRef.
2) I have never heard of a separate Auth Number per service line. The current specification doesn't handle that. Are you coming to the HL7 meeting in Baltimore at the end of September or is this something which you can create a Tracker item to explain and then attend a Financial Management conference call to discuss? We meet Tuesdays at 11am Eastern.

Do you mind sharing in which country you are looking to apply this?

Fred Switzer (Aug 08 2018 at 14:17):

@Paul Knapp
Unfortunately, that's what I suspected. We talked a couple weeks ago at a Tuesday call about approved quantities versus monetary amounts and I got the impression then that some of the use cases here in the USA aren't supported by the FHIR spec as it stands now, at least for Preauthorization. I'll add a tracker item to explain our use cases, but in short, a few payers provide distinct Auth numbers for each service line, although they might also supply an overall reference number that I'm sure we would put in the preAuthRef field as is appropriate.

Could you also answer a very similar question about a related item? Our payers also sometimes provide a date period during which the authorization will be available. This date period can also be specified at the service line level. In my investigation of the ClaimResponse resource, I was unable to find a date period field that could be used at the service level, or even one that could be specified at a higher, overall level.
Would it be better to add individual tracker items for each of these fields, or would the concept of service line authorization numbers and effective periods be better applied to a single tracker item?
Thanks for your help, Paul.

Paul Knapp (Aug 08 2018 at 20:47):

@Fred Switzer If the payer needs to redefine the line to supply allowable date, quantity, provider etc. then they should use .additem which has your needed elements I expect.

Lloyd McKenzie (Aug 10 2018 at 00:09):

@Paul Knapp In a ClaimResponse - which represents the actual "preauthorization", why are there 0..* insurance.preAuthRefs? Wouldn't there always be a maximum of one 'string' that's used to reference a particular preauthorization?