Stream: implementers
Topic: ExplanationOfBenefit: adjudications vs. benefitBalance, etc.
Karl M. Davis (Mar 12 2018 at 18:37):
The ExplanationOfBenefit resource has a couple of fields that look appropriate for representing the various financial amount fields that Medicare claims include (e.g. 'Payment Amount to Beneficiary', 'Indirect Medical Education Amount', 'Submitted Charge Amount', etc.). Those fields are EOB.benefitBalance and EOB.item.adjudication. What's not super clear to us right now is when it's appropriate to use one vs. the other vs. extensions. Anyone have guidance/better documentation on that? (Might be more obvious to someone better versed in the insurance world than I, but alas.)
cc @Paul Knapp @Dave Holdgrafer
Karl M. Davis (Mar 12 2018 at 18:40):
A particular complication we are running into with Medicare claims is that Eob.item.adjudication looks like a better fit for our needs in a structural sense and a domain sense, but it's only available at the item/line level. A lot of our financial amounts appear at both the claim header and line/revenue center levels -- and we need to include both, as the line-level values don't always add up cleanly to the header amounts (just a reality we have to deal with).
Karl M. Davis (Mar 12 2018 at 18:43):
I'm leaning towards sticking all of our claim header financial data into extensions, because benefitBalance seems targeted at a completely different use case (e.g. lifetime limits, deductible balances, etc.) that we don't have data for, anyways.
Mark Scrimshire (Mar 12 2018 at 18:45):
@Karl M. Davis The FM work group has been looking at these "totals" fields and you can expect some changes in STU4 that should make these values easier to represent.
Karl M. Davis (Mar 12 2018 at 18:45):
(Per my email history, Paul+Mark, we may have discussed this on an FM call at the end of 2016, but I can't find any notes on the discussion's outcome.)
Mark Scrimshire (Mar 12 2018 at 18:48):
@Karl M. Davis http://build.fhir.org/explanationofbenefit.html in the latest build has a total (backbone element 0..*) with category and amount fields (1..1)
Karl M. Davis (Mar 12 2018 at 18:49):
(@Mark Scrimshire Weird -- I can @ you now, but couldn't earlier. Glad you found this thread.)
Great news! Do you have any details on those changes? I'm not seeing anything obviously appropriate on the trunk version: http://build.fhir.org/explanationofbenefit.html
Mark Scrimshire (Mar 12 2018 at 18:49):
go to http://hl7.org/fhir/directory.html and choose the latest build
Karl M. Davis (Mar 12 2018 at 18:49):
Ahh, I see that now.
Mark Scrimshire (Mar 12 2018 at 18:50):
v3.2 I beleive
Paul Knapp (Mar 12 2018 at 18:54):
Hi @Karl M. Davis The financial fields you mention would be in EOB.item.adjudication, and totals would be in the EOB.total. The .benefitBalance would hold the consumed quantities under the plan, for example number of Physio visits or amount of Dental benefits used to date.
This allows you to express at the item. or detail. or subDetail. level what can be expressed there and at the root what can only be expressed there or totals of item, detail or subDetail amounts, for example amount charged or benefit payable.
Karl M. Davis (Mar 12 2018 at 19:15):
Overall, I think our mapping of Medicare data to EOBs needs some rework (in a future release; no time for this first release). It's hard to say exactly what our issues are, though, given the sparse documentation for the resource and lack of examples.
Some for-instances:
- We're not making any use of EOB.payment.
- We're also not using EOB.totalCost, EOB.unallocDeductable, or EOB.totalBenefit.
- Related to above: We're probably shoving more things into adjudications than we really should.
- Our Part D (prescription drug) mapping is probably abusing the resource by always having a single EOB.item.
- We've got a lot of extensions. Some of them are probably better mapped to standard fields.
Again, the folks who've built out this mapping (myself included) aren't insurance domain experts. This makes the missing documentation and examples particularly painful for us.
All that aside, we've found the STU3 EOB resource to be a good fit for our usecase. Kudos to @Mark Scrimshire and the FM WG for it!
Paul Knapp (Mar 13 2018 at 05:29):
@Karl M. Davis Hi Karl, that's a lot of items, I'll try to address below:
EOB.payment - that's up to you how much of the payment details you convey to the patient (the typical audience for an EOB). If you paid the provider on the patient's behalf then you probably won't want to put any payment specifics beyond the amount and date into the EOB.
.adjudication - can you provide me with a list of what you are stuffing in and I/FM can review to see if these are normal and appropriate adjudication results.
Prescriptions: nope not abuse, pharmacy has typically allowed only a single line item in a claim - in the US you will receive most pharmacy claims via the NCPDP (SDO) teleplan standard - it only supports a single line item.
Extensions - when we last reviewed your use of the EOB you were down to 2 extensions (assuming the recommendations where implemented) those being Race and Ethnicity. Please send me a list of the others and we can advise on what elements should be used or where new elements or formal extensions are required.
Regarding the lack of documentation, yes with limited resources we have focussed on the content models themselves but expect to have additional resources soon to provide the documentation to support/explain the resources and the business.
Karl M. Davis (Mar 14 2018 at 04:08):
@Paul Knapp We have lots of payment fields, but they're currently mapped as adjudications. One of the reasons we're not using EOB.payment right now is that it's not clear who/what it's supposed to capture payments _for_: payments from the primary insurer to the provider?, payments from secondary insurers to the provider?, payments from the patient to the provider?, reimbursements from the insurer(s) to the patient/beneficiary?, etc.
Paul Knapp (Mar 14 2018 at 10:12):
@Karl M. Davis You would only capture in payment what you, the payor, are paying in respect of this claim. Others speak for themselves, and any Patient payment amount would be reflected in the EOB.total structure in R4 (and actually payor comments on patient contribution is editorial as the patient may have insured against them - ie. they are picked up by a downstream payor).
Last updated: Apr 12 2022 at 19:14 UTC
