Stream: (old) Da Vinci ePDx
Topic: authnz for `$member-match`?
Isaac Vetter (Feb 26 2021 at 14:47):
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 (Feb 26 2021 at 14:47):
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?
Lloyd McKenzie (Feb 26 2021 at 15:26):
@Mark Scrimshire
John Moehrke (Feb 26 2021 at 15:55):
Ill guess... "smoke and mirrors"
Josh Mandel (Feb 26 2021 at 16:00):
Is [a member-mediated authorization mechanism] the case with this EMPI/coverage lookup operation as well?
If that was the case... I don't think $member-match would be necessary, right? So "out of band" (polite re-phrasing of John's comment) seems like the intention. To be clear, I'm not saying I agree with this design choice; I'm just trying to follow the implications here.
John Moehrke (Feb 26 2021 at 16:44):
I so wanted to find good emoji to express.. but my emoji foo is not strong enough... :dragon_face:
Isaac Vetter (Mar 01 2021 at 16:06):
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 01 2021 at 16:06):
Mark, is there any intent to enable backend services, or alternatively, to remove $member-match from the IG?
Last updated: Apr 12 2022 at 19:14 UTC
