FHIR Chat · Feedback about Claim resource

Stream: implementers

Topic: Feedback about Claim resource

nicola (RIO/SS) (Dec 27 2017 at 10:12):

Hi, what the reason to do all this linking in Claim Resource (careTeamLink, diagnosisLink etc). This makes Claim resource "hard to work with" - we have to deal with graph structure. Why not just embed this information into item element: Claim.item.diagnoses or Claim.item.careTeam

Lloyd McKenzie (Dec 27 2017 at 17:08):

@Paul Knapp? (I'm not clear on this myself - it seems these should be able to be references as those are the standard way of linking to resources everywhere else. The minor savings of integer vs. URL doesn't justify the added overhead of a completely new way of referencing.)

Paul Knapp (Dec 31 2017 at 06:02):

@nicola (RIO/SS) I'm not clear as to why this would be hard. its a pattern used elsewhere. We could repeat the complete subclasses (careTeam, diagnosis, etc) the for each item but that would make things like searching for claims for a given diagnosis or involving a given practitioner more difficult - its always a trade off. Please come to an FM conference call or the Wednesday meeting at the WGM to discuss.

Lloyd McKenzie (Dec 31 2017 at 06:34):

Why would it be hard if it's a Reference - that's just a URL?

Eric Haas (Dec 31 2017 at 12:48):

@Paul Knapp "its a pattern used elsewhere" outside of a FM resource where?

Paul Knapp (Jan 02 2018 at 08:58):

@Lloyd McKenzie But it isn't an url its a subclass. If the suggestion is to create separate careTeam or other subclasses on each item element then a search for provider would require examining the careTeam subclass on each item rather than searching within a single careTeam subclass.
@Eric Haas questionaire/questionaireResponse use linkids.

Lloyd McKenzie (Jan 02 2018 at 15:07):

I don't understand what you mean by "subclass". For diagnosis, you're pointing to either a Condition or CodeableConcept. For CareTeam you're pointing to Practitioner (which means the element is misnamed - CareTeam in FHIR refers to a group and element names are expressed in the singular); procedure you're pointing to Procedure or CodeableConcept; I have no clue what you're pointing to for "information" because the spec doesn't make that clear. Yes, you've defined extra information about the condition, pracitioner or procedure, but each should only be listed once at the root, so you can still handle it with a resource reference or just by stating the code again - you don't need to link with integers.

Lloyd McKenzie (Jan 02 2018 at 15:08):

With QuestionnaireResponse.linkId, we're linking across resource instances to something that isn't itself a resource instance.

Paul Knapp (Jan 03 2018 at 07:17):

@Lloyd McKenzie I think you are suggesting several things:
1) That it would be better to name the 'careTeam' subclass to 'provider' as it is a list of providers.
2) Where a reference or a code could be used to scan through the subclass, such as diagnosis or provider or procedure, to locate the subclass instance rather than using a link to a sequence number or other content in the subclass. I agree this can work as long as the contents of the linking element is unique, ie. for diagnosis as long as there aren't multiple claim.diagnosis instances which contain the same claim.diagnosis.diagnosis.

so instead of the current element:

definition
item.diagnosis 0..* positiveInt

example
<item>
<diagnosisSequence value="3"/>
...
</item>

we would have:
definition

item.diagnosis 0..* CodeableConcept | Reference(Condition)

example
<item>
<diagnosisCodeableConcept>
<coding>
<system value="http://hl7.org/fhir/sid/icd-10"/>
<code value="123456"
</coding>
</diagnosisCodeableConcept>

or
<diagnosisReference>
<reference value="Condition/AB12345"/>
</diagnosisReference>
...
</item>

Simone Heckmann (Jan 03 2018 at 13:49):

@nicola (RIO/SS)
We've had the same issues with Claim.
We understand the Claim as a kind of Document, where all information is somehow "embedded" rather than referenced. Invoice is aiming to be knit more tightliy into the whole preceding (FHIR-based) workflow.
Maybe the draft for the Invoice Resource which collects ChargeItems might be a better fit for your use case?
http://build.fhir.org/invoice.html
http://build.fhir.org/chargeitem.html

Lloyd McKenzie (Jan 03 2018 at 16:20):

@Paul Knapp Are there situations where having the same diagnosis or practitioner multiple times could make sense?

Paul Knapp (Jan 04 2018 at 11:28):

@Lloyd McKenzie Perhaps on diagnosis (eg. admitting and discharge), certainly on practitioner (eg. primary and assisting).

Lloyd McKenzie (Jan 04 2018 at 15:27):

And the applicability of the diagnosis or practitioner for the item would be dependent on the use of the diagnosis or function of the practitioner and the relevant diagnosis use or practitioner function wouldn't be inferrable from the item?

MaryKay McDaniel (Jan 04 2018 at 20:39):

Hi all,
As you are most painfully aware, I'm not technical so much of this thread I don't understand.

The US does make the delivery and payment of health care exceedingly complex and includes that level of complexity into the claims that are sent from a provider to a payer. I've never had a developer tell me they made a lot of good sense or were straightforward. in addition, a claim sent stands as a legal document - providers can go to jail or pay some steep fines/penalties, lose contracts depending on what they put in them. So, from a payer perspective, I never 'infer'.

So in response to the 'inferable from the item' note above, I believe the response is no.
Here's one example: In the case of a 200 or 300 line claim, I can have a provider who is credentialed as an OB or a GYN or as an OB/GYN. There are services/procedures that can or cannot be performed by that provider depending on that credentialing. If the provider in the previous sentence is overseeing a student (the provider is acting as a Supervising Physician to the student), the student can only perform the services/procedures the Supervising Physician can. BUT that same student can perform services under a different Supervising Physician - for the same patient, within the same Dates on the same claim. So each claim line must be associated with a DX, procedure, the student physician AND the Supervising Physician and each must be identified as to the role they are performing for that claim line/expense/procedure/service...

In addition, those relationships can change the outcome of the claim adjudication process - i.e., the patient can end up paying more (or less).

MaryKay

Aaron Seib (Feb 23 2018 at 16:32):

I am trying to synthesize some records for a demonstration I am working on. I have two sides of my demo. On the one side I am getting an EOB resource from a Payer system. From the other side I am getting Clinical Resources from a Provider System. I have synthetic data from the Payer System for N# of Personas. Similarly I have K# of personas from the Provider system.

What I am trying to do is map resources from the Provider system into EOBs and go from EOBs backward to clinical resources.

I suspect that the Claim resource is the pivot artifact for me to make this happen but I can't find a mapping that tells me which data elements originate from where. My assumption (which may be sophomoric) is that Clinical Resources map to Claims Resources which Map to EOB resources.

Does anyone have these mappings documented that I can use? Is it published somewhere else already? TY

Lloyd McKenzie (Feb 23 2018 at 16:43):

@Paul Knapp

Paul Knapp (Feb 23 2018 at 19:46):

@Aaron Seib I don't understand what you are trying to achieve so it is hard for me to comment on how you are trying to achieve it. I'm also not sure that what you are doing represents a use case which normally occurs or which we sought to support.

In general clinical information is recorded, goods and services are provided and claims to insurers for a subset of services occur, as do bills to patients. And clinical information may or may not be provided to insurers as data elements or as resources referred to in the Claim, or as a Communication which may or may not refer to the Claim or through out of band communication - for example the insurer may have access to the patients clinical data so that it can fulfill its own clinical data needs. The EOB refers to the Claim, so you can tie some of this together, but won't general contain or refer to clinical resources.

You will only be able to relate clinical resources to claims where the clinical information is provided expressly by the provider for that Claim - not when the exchange is out of bounds or the insurer has independent access to clinical information. You will also not be able to link clinical data which the insurer already has to other claims for which that data was not additionally supplied or requested.

You also can't assume that clinical data supplied but NOT requested by the insurer is relevant in the eyes of the insurer - providers often over-supply data to minimize the likelihood of downstream questions which helps to minimize delays in settlement.

In summary you will know some of the relations from clinical to financial but not all and have no measure of the proportion, AND have no sense if any of the relations are relevant - you will have a partial model of 'I thought you wanted this'.