Stream: implementers
Topic: financial transactions
Simone Heckmann (Mar 09 2016 at 15:25):
Is there a FHIR equivalent for the information that is captured in FT1-Segments of DFT messages in V2 (financial transaction) ?
Paul Knapp (Mar 09 2016 at 17:23):
I'll check, can you give me a quick overview of those elements - it has been a few years.
Simone Heckmann (Mar 09 2016 at 18:56):
I guess the (80%) would be a transaction id, transaction code, quantity and date. A billable item, more or less...
Paul Knapp (Mar 09 2016 at 21:35):
OK, this is the Financial Transaction, a part of the Accounts and Billing (FIAB) artifacts of FM. We haven't begun on that family of artifacts we have been working on the FICR resources, except for account.
Paul Knapp (Mar 09 2016 at 21:37):
@Simone: you'd need account, maybe more.
Paul Knapp (Mar 10 2016 at 06:01):
Looking at FT1: Looks like you'd need most of the fields and would replace fields such as Health Plan ID, Filler Order Number, Perfromedby, OrderedBy and Payment Reference ID, with 'Identifier|Reference(resource)'. All transactions need to go against an Account.
Simone Heckmann (Mar 10 2016 at 10:44):
Not sure I understand. I have system A (e.g. lab) that delivers some service (e.g. blood test). System B is responsible for billing and holds the Patient's Account. Now A wants to post a billable item (the lab test) to the Patient's account. So - what resource does A post to B?
Lloyd McKenzie (Mar 10 2016 at 23:08):
We have the notion of a BillingItem resource that doesn't exist yet.
Paul Knapp (Mar 11 2016 at 15:45):
A posts a Financial Transaction but that Transaction needs to refer to the related Account - in V2 that is supplied in a separete segment, in FHIR that would be a reference in 'the resource called Transaction'.
Simone Heckmann (Mar 14 2016 at 15:45):
Where would I aim someone who's interested in working on the BillingItem Resource?
Simone Heckmann (Mar 14 2016 at 15:54):
BTW: IMHO the Claim.item Backbone element might be a good candidate for BillingItem. It pretty much has everything that V2-FT1 had.
Paul Knapp (Mar 15 2016 at 18:31):
Financial Management Work Group meets Fdiday at 1PM Eastern, or they could contact me directly. Yes there will be a structural similarity between the Financial Transactions (charge items) and the billed items reflected in a Claim but they are not representing the same concept.
Simone Heckmann (Jun 12 2016 at 05:39):
Is there already a draft for the billable item resource out there?
Brian Postlethwaite (Jun 13 2016 at 22:09):
Not that I know of.
Lloyd McKenzie (Jun 13 2016 at 23:16):
So feel free to start one and pass it on to the FM work-group :)
Brian Postlethwaite (Jun 14 2016 at 00:55):
or send it to PA (it's been identified as one of the overlapping resources between our domains)
Joining the finance stuff into the encounter/episodes
Simone Heckmann (Jun 14 2016 at 16:47):
Could anyone please create a draft Resource, based on the Backbone element Claim. item (http://hl7-fhir.github.io/claim-definitions.html#Claim.item) minus the detail element plus an identifier element...? I have an interested party and may be able to provide feedback, but we need something to start with.
Thanks!
Grahame Grieve (Jun 14 2016 at 23:36):
@Paul Knapp - thoughts?
Andy Stechishin (Jun 14 2016 at 23:52):
This was discussed at length during the early periods of the analysis and although feasible did not reflect any running application that we could locate. Another way of looking at this would be to make Address a resource because someone wished to update individual Addresses and not the entire Patient (this is actually a common practice and level of granularity in RESTful systems outside of Healthcare). @Simone Heckmann would you like to come to FM on Friday to discuss your proposal and outline the use cases for this new resource?
p.s. @Grahame Grieve Paul is likely only thinking of how soft his pillow is for at least the next 4 hours
Paul Knapp (Jun 15 2016 at 07:19):
@Grahame Grieve: I answered the question above. There is already prior art in HL7. The service providing system cuts a Transaction which goes against the account. There is not a one-to-one correspondence between the services provided and billable items on the Claim - using the prior example: a woman may receive many (dozens) goods and services (procedures) while in hospital all of which may result in a charge for cost accounting, clinical item accounting, inventory, personnel management etc. And then a formal or informal 'grouper' mechanism issues a claim for a 'normal delivery'.
Paul Knapp (Jun 15 2016 at 07:22):
If someone wants to take the existing V2 / V3 finacial transaction as a starting point and model the FHIR version of that and bring to FM then great. FM has been clear that we had finite bankwidth and chose to work where there was visible demand on the FICR not the FIAB materials and we are working to complete the significant majority of those.
Paul Knapp (Jun 15 2016 at 07:25):
The FIAB 'account' resource has been started thanks to efforts by PA and the FM regulars have periodically reviewed and commented but haven't previously had the implementer bandwidth to structure and flesh-out the FIAB resources - which I think sould be done as a suite to ensure coherence.
The FICR are primarily for exchange between organizations, whereas FIAB is primarily for exchange within an organization.
@Lloyd McKenzie: when you are saying we have the notion of a 'billing item' resource you are referring to the Financial Transaction aren't you?
@AndyStecheshin is correct, FM considered the notion of the line item as a separate resource rejected as: this didn't reflect the granularity of information exchange; or what systems did, and just created more work for the parties.
Grahame Grieve (Jun 15 2016 at 07:52):
Thanks Paul, I was checking that you had seen it
Paul Knapp (Jun 15 2016 at 09:17):
Thanks for the heads-up.
Simone Heckmann (Jun 15 2016 at 09:29):
V2 DFT transactions are widely used in Germany and we will certainly need something similar for FHIR. The reason why I nominated Claim.item as a starting point was that it already reflects the structure of FT1 segments and will presumably fit well with the present use cases.
Paul Knapp (Jun 15 2016 at 10:50):
Yes the structure is similar, I just didn't want the differnces in purpose to be lost in the discussion. Also the FT needs to link directly to the account and probably to the issuing system as well (I have't looked at those specs in awhile).
Lloyd McKenzie (Jun 15 2016 at 14:05):
@Paul Knapp To me, "billing item" is an assertion that points to (or from?) a service or supply and indicates the associated cost and/or charge. There isn't necessarily enough information for a full financial transaction because the respective credit and debit accounts may not be known or declared. If the expectation is to use a FinancialTransaction resource with the source and target accounts omitted, that could work. Is the FinancialTransaction resource created yet? I think that's what's being asked for.
Paul Knapp (Jun 15 2016 at 15:06):
Ok then - best to refer to it as a charge rather than a 'billing item' because it isn't directly related to the bill. No this hasn't been created yet as per my FIAB discussion above.
Points to the creating service and the account. The accounts need to be known at the time or creation or resolveable later from content within the resource.
Lloyd McKenzie (Jun 15 2016 at 17:06):
Agree the accounts need to be resolvable, but this may be a job that the financial system needs to figure out based on patient, department, type of charge, type of encounter, etc. On the other hand, knowing the cost/charge for an item can be relevant for clinical decision-making and/or may need to be asserted at the point of care delivery rather than being left to the financial system to infer (though the latter can certainly occur as well.)
Keith Boone (Jun 16 2016 at 06:28):
Definately looking for a Charge resource here.
Simone Heckmann (Jun 16 2016 at 12:22):
Agreed.
Cooper Thompson (Jun 16 2016 at 18:49):
Would it make sense to have the new Charge resource reference an Encounter instead of an Account? Systems would then determine which Account to post the charge to by checking which account is associated with the specified Encounter. This can address cases where a single account is shared across multiple encounters (i.e. recurring series, or 72-hour readmission, etc.). I agree that a Charge needs to *end up* associated with an Account (in the billing system at least), but there may not always be a direct relationship between the Charge and Account that the system submitting the charge would know about.
Brian Postlethwaite (Jun 17 2016 at 00:47):
In discusssions in PA, the Charge (BillableItem is what we've been calling it to date) will definitely be linking to the encounter, we have been discussing if it should refer to an account or a coverage (think account is the current choice in the design)
Paul Knapp (Jun 18 2016 at 11:43):
The charge must eventually be associated with an account, otherwise there is no 'charge'. It may also be associated with an encounter. Typically the account is associated with the patient, or group of patients, and will include all encounters with teh provider organization.
Paul Knapp (Jun 18 2016 at 11:45):
The account would link to the coverage, the charges to the account.
Lloyd McKenzie (Jun 19 2016 at 02:52):
Well, the "charge" must eventually result in a financial transaction. That will certainly have accounts. It's not clear that billing item needs to though - depends whether most systems do that or it's sufficient to link to patient/department/etc.
Keith Welch (Jun 20 2016 at 00:12):
I had hoped that FHIR would include an Adjustment resource. Arriving at account balances appears to require more than the Charge and PaymentNotice. PaymentReconciliation seems to deal with bulk/batch payments. Am I missing something that accounts for adjustments?
Brian Postlethwaite (Jun 20 2016 at 03:45):
I would imagine this will be part of the transactional stuff when it is added (not currently there)
Paul Knapp (Jun 20 2016 at 11:17):
We are talking about a "charge" not a "billing item". The "charge" is the Financial Transaction from V2/V3. Charges are dropped into an Account, Bills draw from an Account, but typically with some processes (maybe human, or a grouper service, or other) to mediate between what has been "the charges" and how they are billed.
Keith Welch (Jun 20 2016 at 13:08):
I look forward to seeing an adjustment to complete the financial transactions then. I have just noticed that systems that I can relate to financial activity just tend to get PAID FOR a lot more often by those signing off on the funding. Healthcare is still a for-profit activity in some countries.
Paul Knapp (Jun 21 2016 at 06:57):
Well just because the organization doesn't intend to make a profit doesn't mean the personnel and suppliers don't need to get paid, it actualy means the organization intends to spend all the money it receives.
Simone Heckmann (Jun 21 2016 at 08:53):
I'm with Lloyd on the fact that there must be a way for a subsystem to simply link Charges to an Encounter, as determining the proper Account may be too costly or even impossible for the client. I guess in many cases it may require some server side post-processing or even user interaction to drop the charges into the proper account. @Bettina Lieske : What's your take on this?
Paul Knapp (Jun 21 2016 at 10:27):
It must have the patient and It may well be appropriate to contain encounter, device, department of other contextual information in the charge transaction, I'm not disagreeing - but they aren't a substiture for Account. The organization may choose to populate the account information at any time - preferrably before the patient settles the account.
I have said nothing here about whether the client or the server should determine that information, nor what back-end services should be handled by the server or to server supporting services which will interact as clients.
Bettina Lieske (Jun 21 2016 at 11:47):
Great discussion, very valuable.
I would see it like this: performed services are linked to encounters in the subsystem or clinical system (this is what happened in reality).
How they then get grouped together for billing (in terms of charges) and to which account they are billed to is then something is determined by an accounting system.
Not sure what you (@Paul Knapp ) mean by billing items: is this the performed services? They then could be mapped to a single charge for an inpatient DRG case, right?
Paul Knapp (Jun 21 2016 at 12:44):
@Bettina Lieske charges are performed services which may be grouped into one or more billed services.
Bettina Lieske (Jun 21 2016 at 14:16):
I guess we have the same concepts, but use different terms. Is there a draft resource model with definitions containing objects like PerformedService, Invoice, Account, Claim, BillingItem that I could map our terms to? You also mentioned v3. Is there a mapping from v3 entities to FHIR resources (maybe a draft one)?
Most probably a concrete example would help a lot.
Paul Knapp (Jun 21 2016 at 15:48):
If you follow the tread from the top you will see descriptions of 2 suites of materials FICR (Claims and reimbursement) which FM has developed resources for including Claim - see the Financial Tab in the top FHIR banner. The in-organization resources (FIAB) are the Accounts and BIlling ones and we haven't gotten to them yet although PA has a starter for Account.
Brian Postlethwaite (Jun 21 2016 at 20:18):
And the current version of the Account resource is very draft, but has had a couple of rounds of review, so is getting there.
(Known missing bits are mainly the linkages to Encounter/EpisodeOfCare/Coverage)
Daniel Lanphear (Feb 06 2017 at 18:49):
There doesn't seem to be a way to link a claim back to an eligibility response - in a pre-approval scenario, it seems like the claim should have a link back to the eligibility response both for processing and auditing.
There's a string value Claim.insurance.preAuthRef, but it seems like a placeholder, and that an EligibilityResponse reference similar to coverage or claimResponse would be appropriate.
(edited per Kevin's note)
Kevin Olbrich (Feb 06 2017 at 19:08):
@Daniel Lanphear Actually, I was thinking a Claim should have an optional reference to an EligibilityResponse
Kevin Olbrich (Feb 07 2017 at 19:42):
@Lloyd McKenzie Do you have any insight into this?
Lloyd McKenzie (Feb 08 2017 at 04:23):
Based on Workflow, Claim is a Request. So it should have a "basedOn" link to Claim for sure. EligibilityResponse I think is about eligibility for Coverage, not eligibility for a particular type of charge.
Paul Knapp (Feb 08 2017 at 18:29):
If there is a need to provide a reference to an EligibilityResponse it could be provided as a resource reference in Claim.information.
What is the business purpose for this? Is there a concern that a provider may send an EligibilityRequest to determine whether a person has coverage at some point in time, either a simple 'is this coverage in force' or 'does this coverage cover this class of services' and receive a positive response. And then at some later date a claim is submitted and denied due to lack of coverage? If so the frequency of this is so rare that it wouldn't warrant sending the Payor's eligibilty response back to them on each claim, rather you may wish to quote that response in the event the claim is denied.
If we are talking pre-approval then you have the preauth reference and the Eligibility is NOT a pre-authorization.
Lloyd McKenzie (Feb 08 2017 at 19:08):
Claim.information is a bit more generic. We generally try to have more specific associations for things like "why". The notion of supporting information is more for "here's extra stuff that may be relevant when you're trying to execute". For example, past surgeries and allergy information when making a referral.
Daniel Lanphear (Feb 09 2017 at 15:49):
Thanks, that's helpful - we're trying to understand the best approach to the workflow. It sounds like we don't need eligibility at all, but looking at claim in greater details:
Pre-Authorization - where the provision of goods and services is proposed and either authorization and/or the reservation of funds is desired.
If we want pre-authorization, would this be a reasonable approach?
- submit a claim with a minimum amount of information such as insurer, organization, practitioner, patient, and use=proposed
- stop If the claim response includes an error that the patient isn't covered or eligible
- send a more complete claim including the proposed treatment details if the claim response includes an error requiring more information
- if the proposed claim is approved, then proceed with treatment, and follow up with a complete claim including preAuthRef to the proposed claim.
Daniel Lanphear (Feb 09 2017 at 20:42):
@Paul Knapp ^^ does that sound reasonable?
Daniel Lanphear (Feb 10 2017 at 19:40):
@Lloyd McKenzie Any more thoughts on this workflow?
would a proposed claim use Claim.information.timing or Claim.item.servicedDate for the proposed date? It looks like Claim.information might be intended for exceptions The example uses servicedDate with some (proposed) items.
Lloyd McKenzie (Feb 10 2017 at 20:50):
This sounds like the way the resource is designed to work, yes. The fact preAuthRef is a string rather than a Reference is a little weird as in a pure RESTful world, you should be able to traverse to it and the design should aim for REST support, even if that paradigm isn't yet common in the claims space. The element definitions should make clear how they're used for full claims as well as pre-auths and pre-determinations
Paul Knapp (Feb 14 2017 at 18:43):
If you want to perform an eligibility check then send that and behave in accordance to the response (if Eligibility is a supported resource) otherwise you would send in a claim. If you want to send a pre-authorization then send in the complete question including the services to be provided not a light form of the question.
On pre-determinations and pre-authorization the service date would not required but may be provided as an estimated date and the payor may indicate whether coverage is know not to be inforce on that date.
Correct, Claim.information is where the various forms of 'exceptions' are captured.
The Claim resource is the base model from which it would be expected that jurisdictions or usage communities will develop profiles which will set cardinality and bindings. Often they would set different profiles for different types of business: vision, inpatient, pharmacy, dental etc..
Daniel Lanphear (Feb 20 2017 at 19:59):
@Lloyd McKenzie looking at http://build.fhir.org/claimresponse.html (and potentially all the ...Response resources), is the intention to synchronously return a ...Response to a ...Request (just Claim in this case):
The ClaimResponse resource is the response for the submission of: Claim, Re-adjudication and Reversals.
so the workflow would be to post a Claim, and then have a ClaimResponse returned when processing is complete (provided it's "fast enough")?
The wording http://build.fhir.org/http.html implies a ...Response is appropriate synchronously:
These interactions are performed using POST, PUT or PATCH, and it may be appropriate for a server to return either only a status code, or also return the entire resource that is the outcome of the create or update (which may be different to that provided by the client).
The alternative workflow could be an async ...Response posted back to the server, but that requires authentication in both directions.
The outcome=partial also implies a requirement for further communications.
Thanks!
Andy Stechishin (Feb 20 2017 at 21:19):
@Daniel Lanphear in the FHIR REST exxchange paradigm a POST to Claim would return either the stored resource or the id of the stored resource (as per the specification). In order to return a ClaimResponse, you would need to use either an operation (I am not that one has been defined for this at this point in time) or some other exchange paradigm (such as SOAP). At various Connectathons, the different exchanges have all been proved. In a pure FHIR REST you would POST to Claim and then query (GET) against ClaimResponse using the created Claim id.
In many jurisdictions, claim processing is indeed 'fast enough' and the majority of claims can and are processed in 'real time'. Hope this is helpful.
Lloyd McKenzie (Feb 20 2017 at 23:20):
There are lots of workflow options (check out the workflow page to see them :>). Some support synchronous responses, others allow for asynchronous. The workflow designs (whether for financial or other resources) don't make any presumptions about how the workflow itself is managed.
Paul Knapp (Feb 21 2017 at 12:42):
@Daniel Lanphear: The ClaimResponse is a response to the Claim regardless of whether the Claim is Created, or submitted, or a parameter or some other means is used to exchange the Claim content. The 'partial' is because in some situations a ClaimResponse conveying partial adjudication may be conveyed from the payor to the provider - but if that occurs it doesn't alter the fact that the final 'complete' ClaimResponse will state the adjudication for all Claim.items regardless of whether they have been previously reported on. Yes, frequently claims are required to be processed in real time, for example pharmacy, in which case a Request-Response transport of the same Claim and ClaimResponse would commonly be used but a jurisdiction could also implement the FHIR REST paradigm and these various exchanges have been tested/demonstrated in many Connectathons.
Last updated: Apr 12 2022 at 19:14 UTC
