Stream: Da Vinci PDex
Topic: Consent Attributes (HRex_
Brett Atwood (Jan 31 2022 at 17:47):
If I'm the old/prior payer and I want to write (to my FHIR server) the consent resource that the new payer provided in the $member-match input, what attribute in the consent resource identifies who that new payer is? I think the new payer is intended to be represented in the organization reference identifying the new payer as the 'Custodian of the consent' but (1) that element is not required and (2) if it is populated with a reference, as old payer I have no way to resolve that reference, e.g. it's a meaningless link. How can the old/prior payer be confident that the consent resource captures the identity of the new payer - or can't they?
Brett Atwood
IBM Watson Health
Lloyd McKenzie (Jan 31 2022 at 18:16):
You're right. There should be a slice in the Consent that captures the data source authorized to disclose, not just the information recipient they're allowed to disclose to. Can you submit a change request?
Brett Atwood (Feb 01 2022 at 15:42):
Request submitted - my first one (so hopefully I've done this correctly). https://jira.hl7.org/browse/FHIR-35912
Lloyd McKenzie (Feb 01 2022 at 15:43):
Looks good. Thanks!
Stephan Roorda (Feb 01 2022 at 17:06):
OK, so I am confused by the response of
"There should be a slice in the Consent that captures the data source authorized to disclose, not just the information recipient they're allowed to disclose to."
For this Consent to have any value to use at all (for auditing, etc) I think we need to know:
a) Who is sending / owns the consent
b) Who is sending the data and who is receiving the data
I think we could fill in the values in the Consent resource as follows
- organization reference - Custodian of the consent (who owns/sends the Consent )
- provision.actor with role.coding.code = IRCP for the Org receiving the data the Consent is about
- provision.actor with role.coding.code = PRF for the Org sending the data the Consent is about
All 3 of those are optional currently so there is no guarantee they will be there.
This presumes of course that the IRCP and PRF actors are referring to the actors of the DATA being consented to and not the Consent itself.
Lloyd McKenzie (Feb 01 2022 at 17:25):
It is possible a consent may be open-ended - i.e. "get my prior coverage from anyone/everyone" so the authorization might not be sending payer-specific. However, agree it should always be receiving payer-specific (though there could, in theory, be more than one receiver listed). Not sure how essential the 'owner' is for our use-case. We provide a link to where the source-of-truth for the consent (paper/image/whatever) can be found. What's the use-case for needing the custodian computably represented?
Stephan Roorda (Feb 01 2022 at 19:37):
As part of $member-match we MAY store the consent, per the IG. If I am storing the consent I want to know WHO the consent came from. Who owns that consent? I need to differentiate between consents I own and consents that were sent to me.
I had not considered the open-ended case but at least ONE side has to be filled in right? Either the sender or receiver?
a) I consent to have my data sent from ANY Payer to Payer X
b) I consent to have my data sent from Payer X to ANY Payer
c) I consent to have my data sent from Payer X to Payer Y
d) I consent to have my data sent from ANY Payer to ANY Payer
Is d) valid?
Lloyd McKenzie (Feb 01 2022 at 19:59):
You can choose to capture who sent you the consent if you like. That's not necessarily the 'owner'. However if you have "who gave this to me?" and "where can I find the source of truth?", that should be enough for the use-case?
I think the consent needs to enumerate who the data is sent to. Leaving that open-ended seems too risky. For the use-cases we have, the patient always knows where they want the data to flow to. Making the 'from' open-ended just keeps the paperwork simple.
Daniel Venton (Feb 01 2022 at 21:21):
I would think, with the current plan of requiring a token to do a $member-match, the token itself contains the "who it's from". I would assume that when the clientid/secret was established, there was a record of the organization.
I suspect that most cases are going to be "I consent to data being sent from my previous payer(s), to my new payer."
What new payer is going to manage consents between 2 entities that are not themselves?
Lloyd McKenzie (Feb 02 2022 at 00:23):
It's typically the new payer that's managing the consent. The consent is then passed to the payer(s) being authorized to provide the data.
Stephan Roorda (Feb 03 2022 at 14:28):
OK so back to the original question from Brett
"As the old payer in a business to business payer data exchange scenario, I want the consent record that the new payer provides in the $member-match input to require the new payer is identified/captured/included so when I (as old payer) write the consent record to my FHIR server, I have traceability as to the payer that created the consent record initially."
Ultimately what we need to know is where in the consent do I find who the New Payer is when I receive this consent as the Old Payer on my FHIR server.I. think the fields in the Consent we are referring to (actors) depend on which direction the consent is going?
If we stick with these assumptions
1 - The new payer is managing the consent
2 - The consent is passed to the payer's being authorized to provide data
In the member match flow that means New Payer is sending Consent to Old Payer
So, where and what fields in the Consent identify who is who? I was under the impression in this scenario that
- IRCP would be the New Payer
Is that right? Does the Old Payer (the one receiving the consent) have to be in there somewhere? I think if I am the Old Payer my FHIR server has to put that in there somewhere because otherwise if I am looking at Consents on my server I have no idea which ones are ones I received or ones I own otherwise. It seems like that would be important, to know both sides of the transaction.
Brett Atwood (Feb 08 2022 at 14:50):
Lot's of good discussion here. Just to take a step back, are we able to align on which entity the Information Recipient actor role is intended to represent in a simple P2P data exchange?
Is it:
a) the payer that will be receiving the data/information (e.g. 'new' payer) OR
b) the payer receiving the consent resource/information via the $member-match operation (e.g. 'old' payer)?
In this example from the HREX IG, the implication is the IRCP actor is the 'old' payer and, as a starting point, I think we need to make sure we agree that is or isn't correct.
http://build.fhir.org/ig/HL7/davinci-ehrx/Parameters-member-match-in.xml.html
Lloyd McKenzie (Feb 08 2022 at 14:52):
The information recipient would be the 'new' payer. The example is wrong. I'll fix.
John Moehrke (Feb 08 2022 at 14:52):
good to know.. I was very much confused
John Moehrke (Feb 08 2022 at 14:59):
so would there be a Consent instance for each "old" custodian of data from which data will be gathered? I have not fully followed the discussion but was wondering about this. If more than one "old" are they indicated by multiple .provision.actor ?
John Moehrke (Feb 08 2022 at 15:01):
- Two different alternatives.. two Consent, or one Consent with multiple .provision.actor.who?
Lloyd McKenzie (Feb 08 2022 at 15:06):
We're going to update the consent to identify the data source. If's possible to list multiple allowed recipients, though for the purposes of the exchange, only the requesting payer would be relevant.
John Moehrke (Feb 08 2022 at 15:38):
ah, so there could be an empty list of custodians to indicate ALL findable?
Lloyd McKenzie (Feb 08 2022 at 18:00):
Don't care about custodian, only who's allowed to share. And that will become a 1..* element
John Moehrke (Feb 08 2022 at 18:32):
sorry if I confused. I used the word "custodian" generally as a role of someone who had data about the patient that the IRCP wants to have.
Kyle Brew (Mar 29 2022 at 14:24):
I had another question about HREX Consent in PDEX $member-match flow (please let me know if there's a better place to post this, or if I should just start a new thread)
I see in the HREX Consent profile that source[x] is Must Support. And I see in the member-match examples here, that the sourceReference attribute is simply a link to a PDF.
However what is expected if the consent source is a DocumentReference Resource? Should the DocumentReference Resource be included directly in the $member-match request bundle? If it's a just a link to a FHIR resource I'm not sure how the receiving payer would be able to access that DocumentReference resource.
Daniel Venton (Mar 29 2022 at 14:38):
At one time, part of the input to the operation was going to be a token that could be used to reach back and retrieve the consent resource itself (as well as any supporting docs I imagine). But it looks like everything is supposed to be included in the submission, meaning that there can't be any pure reference elements (unless that reference resource doesn't require authorization I suppose). I also don't know where a pdf would come from... Do I create a pdf of all the elements on the web page where the user clicked "I Consent" and store that as a document?
Last updated: Apr 12 2022 at 19:14 UTC
