Stream: implementers
Topic: Where and how to represent reimbursement amounts
Eric Haas (Mar 27 2018 at 20:18):
GF#15726
- add unit and total cost to ServiceRequest Medium
Discussion within Orders and Observations Workgroup and need to bring to larger community since is not only a ServiceRequest issue. We think that cost of service should be represented using a definition resource and perhaps reimbursement amounts as well. Would like to gather other thoughts prior to organizing cross workgroup discussions.
Lloyd McKenzie (Mar 27 2018 at 20:57):
On ServiceRequest, there are three potential costs:
- the charge for actually creating the order (that's a thing in some areas of healthcare)
- the estimated cost of the delivery of the service
- the "covered" cost associated with the ordered service
Agree that there can also be costs associated with definitions of things - though generally maintained as a separate resource because there can be multiple costs for the same service where the cost varies by date, by type of recipient and by other factors. As well, the authority for the cost information is typically distinct from the authority for the service definition or product definition.
Eric Haas (Mar 27 2018 at 21:21):
GF#15726 specifically covers the third bullet. But they all need homes.
Lloyd McKenzie (Mar 27 2018 at 21:41):
Covered cost typically is expressed using Claim - that's where pre-determinations and pre-authorizations are specified. And it also supports the other information such as who will pay, who's allowed to do the service, the timeframe in which the service is authorized, etc.
Eric Haas (Mar 27 2018 at 22:42):
as discussed in the tracker, the government will pay up to X for service Y Here is just a statement of fact.and this use case is not explicitly described in Claim.
Lloyd McKenzie (Mar 28 2018 at 01:03):
It's still a pre-authorization or pre-determination - the government is the payor. They're determining what they're willing to pay. That willingness may depend on certain criteria and it may have a time limitation. FM hasn't set the resource up to allow for direct assertion of declaration about what's coverered without a request first, but that's not because it shouldn't be possible.
Paul Knapp (Apr 03 2018 at 12:00):
'the government will pay up to X for service Y' is a fee guide type of expression, and is common for payer to express things that way. It is however only part of their full expression, by that I mean health insurance plans typically say something along the lines of: the plan will reimburse X percent of the eligible amount (amount charged up to the amount in the fee guide) lees any co-pay or co-insurance after the specified deductible is achieved to the degree that funds remain (policy limits have not been reached) and while the policy is in force (not cancelled)- and as long as the Coordination of Benefit Order of claim submission is followed, etc. etc.
FM has no plans (or use case or outstanding request) at this time to create a resource of IG for electronically exchanging fee guides.
Lloyd McKenzie (Apr 03 2018 at 17:05):
Fee guides are what's used to generate a pre-determination or pre-authorization - which is what you'd typically want to convey with an order - the downstream provider wants to know what's covered for this specific patient for this specific service as of "now". Fee guide won't provide that.
Jack Wallace (Apr 09 2018 at 18:51):
Isn't part of the problem here the direction of the transaction? Claim currently seems to be geared, at least from examples and scope, to be something where either (a) the entity wanting payment is saying "here is what I want to be paid for what I provided" or (b) the entity that would eventually receive payment is saying "here is what I would want to be paid if I performed this service". So pre-authorization/pre-determination is still from the eventual money recipient essentially proposing some service for some amount of money (i.e. asking permission). What we need to represent is essentially in the other direction, namely that the payor (a state Medicaid agency in the case that started this discussion) saying "the service provider will provide this service at a unit cost of X not to exceed Y". So not a pre-authorization or pre-determination (i.e. actually authorizing the service or at least agreeing to pay for it at that unit/total cost).
I would have no objection to using Claim, but seems like the scope would need to be expanded. And wouldn't there need to be a way to distinguish from the payee saying this is what it would cost versus the payor saying this is what it can cost? In other words, if I just referenced a Claim from ServiceRequest, how would I know at a high level what this Claim represents? Maybe an expansion to the Claim-type code list? But right now, Claim has payor and responsible party and so-forth, but not who generated the sucker since the assumption appears to be that the claim was generated by whoever wants (or will want) payment.
Lloyd McKenzie (Apr 09 2018 at 21:00):
Pre-determiniations/pre-authorizations aren't necessarily always initiated by the payor. It's not uncommon for an ordering/referring clinician to do the predetermination/pre-auth and then pass that information downstream to the pharmacy/referred-to clinician/etc.
Lloyd McKenzie (Apr 09 2018 at 21:03):
And there's technically no reason why a payor couldn't produce an unsolicited pre-determiniation/pre-auth if they wished. E.g. "Our analysis shows that you're due for a pap smear. Your deductable is fully paid for this year. SuperInsurer will reimburse the cost of the service for up to $200. The following doctors in your area provide the service within that range..."
Lloyd McKenzie (Apr 09 2018 at 21:04):
The challenge is that right now ClaimResponse presume that there was a Claim - which there wouldn't be in this situation. (That actually makes ClaimResponse hard to use in the "ordering physician passing to pharmacy/referred-to clinician" use-case too, so I'd love to see the tight coupling between those two resources relaxed for a few reasons.)
Jack Wallace (Apr 09 2018 at 21:34):
Assuming that Claim could be used for this, do you agree that there should be some mechanism for indicating where this "claim" came from, i.e. a payee generated it versus a payor?
Lloyd McKenzie (Apr 09 2018 at 22:36):
It would actually be the ClaimResponse you'd be passing around - that's what shares what will be paid for - and I think in your scenario that's still payor-generated. The difference would be that the ClaimResponse wouldn't point to a Claim.
Jack Wallace (Apr 10 2018 at 14:08):
If ClaimResponse is what we would use to represent, we have not only the issue with the scope not being broad enough, but in our case we also need unit cost and total cost for a service; so for example for a service providing transportation we need to be able to document the unit cost allowed per mile as well as the total cost allowed for all transportation. Claim has unit and total, claim response only has total.
Lloyd McKenzie (Apr 10 2018 at 17:08):
Right. ClaimResponse doesn't tell the whole story because it presumes knowledge of the Claim. Which doesn't allow for use-cases where you want to share the response without the claim or there might not have been a claim at all. I think the ClaimResponse needs to be refactored to allow it to be stand-alone. This will involve some degree of duplication of information of what's in the claim - just as there's often duplication between other Request and Event resources. It should be possible to tell just from looking at the ClaimResponse exactly what's covered and what's not and for how much without looking at the Claim at all.
Last updated: Apr 12 2022 at 19:14 UTC
