Stream: Da Vinci PDex
Topic: Consent Attributes (HRex)
Lloyd McKenzie (Mar 29 2022 at 15:51):
Agree that the documentation is somewhat misleading by having the ".pdf" on the resource id - it looks like a file extension. It's not a link to a PDF. It's a pointer to a DocumentReference (which presumably contains a PDF). I've submitted a tracker item to remove the ".pdf" from the example URL. (FHIR#36670)
Kyle Brew (Apr 05 2022 at 14:41):
Thanks @Lloyd McKenzie . So if it is supposed to be a reference to a DocumentReference resource I'm still not sure how the payer receiving the member-match bundle submission is supposed to be able to access that separate DocumentReference resource?
@Mark Scrimshire tagging you as well if you had an input on how this Consent source referenced resource would be shared? And also what's an example of what it would capture (e.g., screenshot of consent acknowledgement page?)?
Lloyd McKenzie (Apr 05 2022 at 14:53):
If you need it, just execute a Read against it.
Kyle Brew (Apr 05 2022 at 15:10):
But with what authorization bearer token? The payer receiving the member-match request wouldn't have any authority to access any data from the other payer's FHIR server based on how I'm reading the IG. So unless it's a public endpoint that anyone can execute a read against I'm still not sure how the data is made available
Lloyd McKenzie (Apr 05 2022 at 15:25):
You now have a member id, so can access the Consent in the same manner that you would access any other data on the target server. It just turns into a regular PDex query under the same security protocols.
Daniel Venton (Apr 05 2022 at 16:11):
Having a member id is not the same as having authorized access to a server. If Consumer App provides a reference link to a fhir resource to the Supplier, unless that resource server is open access then the Supplier will not be able to retrieve the resource.
Daniel Venton (Apr 05 2022 at 16:13):
The answer here is that the Consumer app does not provide a reference link, it provides the resource itself as part of the $member-match operation input. And passing a screen shot isn't going to work, it needs to be processable. A screen shot would imply human intervention to decode any necessary value.
Lloyd McKenzie (Apr 05 2022 at 16:17):
If you have patient-mediated access through a consumer app, then the Consent is irrelevant - the patient is right there in the middle determining that data can flow. The Consent is being shared for non-patient-mediated access - i.e. direct payer to payer communication with no patient involvement (beyond the fact that they've signed a consent that is stored somewhere).
Last updated: Apr 12 2022 at 19:14 UTC
