Stream: implementers
Topic: payor's bank account information
Simone Heckmann (May 22 2017 at 17:55):
How and where do we capture a payor's bank account information, e.g. for a patient who is a selfpayor.
We've been thinking Coverage.identifier or Coverage.payor.identifier?
Specifically in Europe, we'd need to capture
1. the Account Number (IBAN)
2. the name of the Bank (presumably optional)
3. the name of the account Owner
4. unique mandate reference (in case of direct credit)
Specifically the last one doesn't fit well in the Identifier data type. So maybe extension?
If so, should this be core extension? European extension?
Extension on Coverage or extension on Patient/RelatedPerson?
Opinions, please!
Stefan Lang (May 22 2017 at 18:00):
2a. the BIC (optional as of February 2016, but formally possible as well)
Simone Heckmann (May 22 2017 at 18:01):
Similar question may apply for credit card information...
Simone Heckmann (May 22 2017 at 18:10):
4.) is definitely related to a specific coverage (Patient giving a mandate to credit wifi/phone bills to his account), so that makes it a direct attribute of Coverage, not Coverage.payor.
Stefan Lang (May 22 2017 at 18:10):
I was about to write just the same ;)
Stefan Lang (May 22 2017 at 18:14):
But 1)...3) are not identifiers of the coverage, since a bank account may be used for more than one coverage. Like, a father's coverage (as a self payor) for himself and each of his children. That contradicts the meaning of "identifier".
So, the bank account data is a property of the payor.
Peter Scholz (May 23 2017 at 06:50):
I guess we don't need the BIC anyhow for two reasons:
a) It was a very special construct during the introduction of SEPA in Europe and is optional since 2016
b) it can be deducted from the IBAN
Peter Scholz (May 23 2017 at 07:03):
"Mandate reference" is definately an european extension as it is specific for SEPA
And IMHO it is an attribute of the Coverage.Payor as it is an information that this payor has authorized
to withdraw charges from his account(s)
Peter Scholz (May 23 2017 at 07:12):
But to make things a bit more complicated:
Neither Coverage.identifier nor Coverage.payor.identifier are the correct attributes for the bank account information as this information solely identifies an distinct bank account but neither a coverage nor a person.
I fear there is a lack of attributes here ;)
Stefan Lang (May 23 2017 at 07:38):
One could misuse a person's/organization's identifier for the bank account, since every bank account or credit card has one single owner, so it is in fact an identifier for the person or organization. But agreed: it feels inadequate.
I also agree on the specific extension for "mandate reference".
regarding BIC and bank name: right, these are optional for SEPA now. The similar applies to credit cards, where the number also identifies the issuer. I don't know whether there is the need to explicitly identify the bank in other areas.
For the moment, I would tend to have an optional reference to an Organization(bank), which would make it possible to have the bank name as Organization.name and the BIC as Organization.identifier (which it is).
That leaves open IBAN and bank account owner which has to be put in context, as Peter pointed out:
"Patient (=benificiary) A pays service B through bank account (IBAN) C, which is owned by (Patient|RelatedPerson|Organization) D"
Stefan Lang (May 23 2017 at 07:40):
(Where D may be identical to A, but not necessarily)
Stefan Lang (May 23 2017 at 07:43):
To make that complete: at the same time Patient (=benificiary) A pays service X through bank account (IBAN) Y, which is owned by (Patient|RelatedPerson|Organization) Z
Stefan Lang (May 23 2017 at 07:44):
(Where Z may be identical to A or D, but not necessarily ...)
Peter Scholz (May 23 2017 at 07:47):
how to express: Service X for Patient A (beeing a child) is covered by Mother B (Related Person) but withdrawn from an account belonging to mothers marital partner C (who is not related to Patient A by any means) . Patchworking can produce interesting constellations :D
Stefan Lang (May 23 2017 at 07:49):
Well, that "unrelated" person in fact would have the relation "Pays A's rent" :D
Stefan Lang (May 23 2017 at 07:51):
At the moment I think at least for that use case the bank account is not an attribute of a person, but of the relation.
Peter Scholz (May 23 2017 at 07:52):
Neither nor,
as the mother is the payor by legal means, she is just using the bank account of C to which she has the right of access
Stefan Lang (May 23 2017 at 08:14):
What I mean is something like:
...
<payor>
<extension url="http://......./mandate-reference">
<valueString value="ABCDEF123456" />
</extension>
<reference value="RelatedPerson/12345" /> <!-- the mother "B" -->
<identifier>
<extension url="http://......./bank-account-owner">
<valueString value="Person C" /> <!-- or possibly a reference? -->
</extension>
<system value="http://............../iban" />
<value value="DE01234567890123456789" />
<assigner>
<reference value="Organization/98765" /> <!-- the bank -->
</assigner>
</identifier>
</payor>
...
Stefan Lang (May 23 2017 at 08:22):
As an afterthought, using an extension instead of the proposed payor.identifier might make it less ugly ...
Stefan Lang (May 23 2017 at 08:25):
As a second afterthought: why does payor have cardinality 0..*? What is the use case for having multiple payors for a single coverage? And if there is one, how would they be prioritized?
Peter Scholz (May 23 2017 at 08:52):
IMHO that looks way to complicated to be right.
Maybe we lack a ressource or datatype denoting a bank account
Stefan Lang (May 23 2017 at 09:07):
Agreed. The above proposed example represents what, to me, seems possible right now (apart from the proposed payor.identifier part should really be a complex extension).
But maybe a bank account can be considered as a necessary part of a coverage and thus become part of the Coverage resource? It is still at maturity level 2.
OTOH, a resource or data type may be better if there are other places a bank account will be used.
Stefan Lang (May 23 2017 at 09:08):
(the latter of course would have to be referenced/used in Coverage)
MaryKay McDaniel (May 23 2017 at 20:04):
Hi,
MaryKay McDaniel (May 23 2017 at 20:08):
Question, is the intent to actually be able to use this to withdraw amounts from the bank account? If so, wouldn't you also need the routing number? I may be present in one place, but my banking information could be in an entirely different country. In addition, would you need more than one 'set' of account information? It is possible I have one savings account, one checking account and a money management account that could be used to withdraw the funds against (or perhaps the 'rule' becomes only one to keep it from getting too complex)?
Ardon Toonstra (May 24 2017 at 08:07):
@Simone Heckmann @Peter Scholz @Stefan Lang just for checking: do you all think the Account resource is not suitable (or shouldn’t be made suitable) for capturing patient’s bankinformation?
Stefan Lang (May 24 2017 at 08:13):
Actual payment is part of the coverage, while Account represents internal accounting (debitors + creditors).
Stefan Lang (May 24 2017 at 08:17):
Depending on the coverage, there may be different bank acccounts in use, which is represented by Account.coverage.
So from my point of view: no, Account does not represent a bank account and modifying it for that purpose would also mean rethinking Coverage at least.
Stefan Lang (May 24 2017 at 08:23):
See also the description of Account.coverage: "The party(s) that are responsible for covering the payment of this account"
Stefan Lang (May 24 2017 at 08:25):
And the description of Coverage: "Financial instrument which may be used to reimburse or pay for health care products and services. "
This surely includes the actual payment information, like a bank account
Peter Scholz (May 24 2017 at 08:26):
@Ardon Toonstra
Right now the Account resource is not suitable to provide a bank account , and I fear it never will be
As @Stefan Lang wrote, the Account ressource is for internal accounting,
we could extend Account to be able to handle external (like bank accounts) but that would lead to a high degree of confusion
As we would have
Account.coverage.account which kinda look like "recursion level exceeded"
Stefan Lang (May 24 2017 at 08:27):
+1 for the recursion argument
Ardon Toonstra (May 24 2017 at 08:28):
Ok, that's very clear. Thnx.
Ardon Toonstra (May 24 2017 at 08:39):
So if I am correct we got the following options:
1. use a complex extension in Coverage.payor
2. add as attribute to Coverage
3. new datatype/resource
Stefan Lang (May 24 2017 at 08:42):
That's the state of the discussion so far. (3 of course would include a modification of or an extension for Coverage as well)
Ardon Toonstra (May 24 2017 at 08:53):
I am leaning towards adding a new backbone element named something like payorInfo or payorBankdetails in Coverage. Not sure if this element will be reused a lot at different places to make it a new datatype. Tracker item worthy?
Stefan Lang (May 24 2017 at 08:57):
I would prefer to have some more international feedback on that before actually starting a tracker item.
Stefan Lang (May 24 2017 at 09:02):
Thinking about bank accounts, I see at least one other use case containing these, which is when practitioners or hospitals send their payment information to some central registry. At least in Germany it is very common that there is a financial compensation when data is sent to a registry.
Stefan Lang (May 24 2017 at 09:05):
That payment information is, along with sender contact data, often part of the structured document containing primarily patient data.
Stefan Lang (May 24 2017 at 09:21):
From that point of view, a new resource may be useful, especially in terms of reusable data, like: there is often a special bank account for third-party funding (registries and also clinical trials)
Sunanda Veeraganti (May 24 2017 at 11:44):
@Stefan Lang I agree with your suggestion. a new resource may be useful. Similar to Germany. There are registries in other countries where practitioners and hospitals send their payment information to the registry for financial compensation.
Lloyd McKenzie (May 24 2017 at 13:30):
I would expect Account to handle bank accounts. I would also expect Accounts to have a recursive parent-child relationship. @Brian Postlethwaite (new) ?
Stefan Lang (May 24 2017 at 14:19):
@Lloyd McKenzie including recursion, in an implementation this would look like:
Account(Profile: "internal-debitor") ---0..n---> Coverage ---0...1---> Account(Profile: "bank-account")
or eventually
Account(Profile: "internal-debitor") ---0..n---> Coverage ---0..n---> Coverage.payor ---0..1---> Account(Profile: "bank-account")
or are you thinking of a direct recursion, leaving the relation between a payor and a bank account undefined:
Account(Profile: "internal-debitor") ---0..n---> Account(Profile: "bank-account")
Lloyd McKenzie (May 24 2017 at 14:35):
I don't think the notion of a guarantor's bank account should be linked through Coverage at all. There's no insurance involved and Coverage is only for insurance. I think Account.guarantor needs to be able to point to the account to be charged for that guarantor - whether a bank account or a credit card account. The current model also seems to suggest that payment is always drawn first from insurance (coverages) and then from guarantors. Are we sure this will always be the case?
Stefan Lang (May 24 2017 at 14:39):
Given that Coverage is only for insurance, why can Coverage.payor be a Patient or a RelatedPerson?
Stefan Lang (May 24 2017 at 14:44):
There is even an example for a self-payor in Coverage: http://build.fhir.org/coverage-example-selfpay.xml.html
Peter Scholz (May 24 2017 at 14:55):
@Lloyd McKenzie
Account.guarantor is by no means useable as we don't use guarantors in Germany at all.
What we need to model is having a person paying for a distinct service during the patients hospitalisation and not someone who guarantees payments for a defined period of time.
Lloyd McKenzie (May 24 2017 at 15:55):
@Stefan Lang Given the definition of Coverage, I have no idea why a Patient or RelatedPerson can be a payor. @Peter Scholz You would have an account that tracks all charges to be billed to a particular individual. Whether that account is for a single service for for 2 years worth of services, you still have a person who is on the hook for paying off that account. It may be that the term "guarantor" carries more bagage than that, but that's the relationship I was meaning.
Andy Stechishin (May 24 2017 at 16:35):
I believe Patient and RelatedPerson were added to support a Use Case that Simone presented.
Andy Stechishin (May 24 2017 at 16:37):
Also, at one time Coverage had BIC which could have been reworked to support both SWIFT and IBAN but it was requested to be removed by PA (I believe)
Simone Heckmann (May 29 2017 at 17:29):
@Andy Stechishin Coverage used to have a BIN which had a very constrained scope.
+1 for a backbone element "payorBankdetails" on Coverage
@Bettina Lieske, @Udo Siefker : How do you handle this data?
Simone Heckmann (May 29 2017 at 17:36):
I wonder if a bank account could be a type of Endpoint ("The technical details of an endpoint that can be used for electronic services...")
Simone Heckmann (May 29 2017 at 17:49):
pity there's no uri scheme for banking details 
Simone Heckmann (May 30 2017 at 06:36):
Hold on! Maybe there is:
https://tools.ietf.org/id/draft-dold-payto-00.html
e.g.: payto://sepa/CH9300762011623852957
Not really a great fit, but very much in the spirit of FHIR ;-)
Simone Heckmann (Jun 01 2017 at 06:54):
Following up the discussion on PA call on Tuesday, I created Tracker Item GF#13471 for Itroduction of a backbone element "payor" 0..* on Coverage, holding the reference to Payor as well as banking details related to a particular payor.
Please provide examples and use cases that will help us to figure out, what attributes are needed to fully capture banking details for different payment methods in different parts of the world.
Does anyone see other places where such a data structure would be needed, other than Coverage.payor?
Ardon Toonstra (Jun 01 2017 at 19:57):
+1 for the tracker item
Last updated: Apr 12 2022 at 19:14 UTC
