Stream: Da Vinci PDex
Topic: authnz for $member-match
Isaac Vetter (Mar 02 2021 at 21:54):
Reposted from old stream
Hi! I'm re-reading PDex. For the $member-match operation, used as an EMPI lookup and to determine coverage when a member moves from one health plan to another, what's the intended method for the new plan to authenticate against the old plan's FHIR server when calling this operation?
Isaac Vetter (Mar 02 2021 at 21:54):
The other Payer-to-payer interactions in this guide (I think) all use a member-mediated authorization mechanism (i.e. the member logs into the old plan to authorize the new plan to access their data via SMART). Is that the case with this EMPI/coverage lookup operation as well?
Isaac Vetter (Mar 02 2021 at 21:54):
An EMPI-type lookup is exactly what would be needed for an authorized backend service to discover a member and their coverages. Was support for authorization mechanisms other than patient-mediated the intent for this operation, and then the IG was retooled to only enable member-initiated? It seems obvious that there would be a ton of value in permitting backend service authorization here.
Isaac Vetter (Mar 02 2021 at 21:54):
@Mark Scrimshire, are you right person to ask if there is any intent to enable backend services, or alternatively, to remove $member-match from the IG?
Mark Scrimshire (Mar 10 2021 at 02:39):
@Isaac Vetter I am not aware of any plan to remove member-match from the PDex IG. It is also referenced in PCDE and is instantiated in HRex. What backend services are you referring to? Are you referring to Bulk FHIR?
Lloyd McKenzie (Mar 10 2021 at 02:49):
I believe the definition of $member-match is moving to HRex where it'll be referenced by PDex, PCDE and anything else that needs it.
Isaac Vetter (Mar 10 2021 at 22:29):
@Mark Scrimshire , thanks for the response. In PDex when calling the $member-match operation, does the caller authenticate with an OAuth access_token? If so, how did the caller get that access token?
Mark Scrimshire (Mar 11 2021 at 15:06):
@Isaac Vetter Following up on Backend services and Member-match in PDex: PDex leaves the door open for payers to use Bulk FHIR to exchange data. We saw clearer definition in that area as being an STU2 item. However we still see a need for member-match to enable payers to confirm that they are exchanging information about the same individual.
The current $member-match assumes that payers will have an endpoint discovery capability (e.g. CAQH / FAST) and some type of verification that enables them to access the clinical apis (using an OAuth Access Token) that are also exposed through the Patient Access API.
Last updated: Apr 12 2022 at 19:14 UTC
