FHIR Chat · member-match in HRex and PDex · Da Vinci PDex

Stream: Da Vinci PDex

Topic: member-match in HRex and PDex

Stephan Roorda (Jan 31 2022 at 16:37):

My question revolves around access to the /Patient/$member-match operation and how it relates to HRex vs PDex. I have read through https://build.fhir.org/ig/HL7/davinci-epdx/index.html and http://build.fhir.org/ig/HL7/davinci-ehrx/index.html and I am still somewhat confused on the nuances here.

1. My understanding from reading HRex is that there are no additional restrictions placed on WHO can access that operation or do they fall under the SMART scopes and I need Patient/*.read?
2. Where do I find if the server SHOULD/SHALL/MUST support $member-match for Patient Access API? I am assuming its not MUST
3. PDex adds additional security in that the requesting payer gets a token that ONLY has access to member-match. Is this in conflict with HRex which has no such restriction?

I have only recently (in the last 2 months) started reading HL7 IGs and I am not totally familiar with how to find all the answers. So if the answer is RTFM that is perfectly OK as it will help me figure out how to decipher this.

thanks,
Stephan Roorda
IBM Watson Health Interoperability

Lloyd McKenzie (Jan 31 2022 at 18:14):

The intention is to migrate the content from PDex to HRex, though the timing of that will depend on how quickly the PDex requirements settle.

1. We haven't talked about operation permissions. I agree that Patient/Patient.read would be the appropriate permission. Would you like to submit a tracker item for us to make that explicit?
2. Expectations for support will be in the CapabilityStatements of the IGs that reference the operation. So HRex won't define conformance expectations. PDex will - referencing the HRex-defined content.
3. That bit is still up in the air. I.e. whether and how to get a token that allows you to perform member match, which then allows you to to get a token to access more information.

Daniel Venton (Jan 31 2022 at 19:18):

How can the token say patient/Patient.read when they don't know the patient id and can't express it? Maybe system/Patient.read?

Daniel Venton (Jan 31 2022 at 19:28):

I would think that this is one of those scenarios where the app id (from app registration) would dictate this app has $member-match permission instead of a specific fhir scope, especially since it's not getting a resource so FHIR based resource scopes seem odd, all it returns is some value that can be used in a token request for an actual scoped token. Which would likely include patient/Patient.read with sub="patient id".

Stephan Roorda (Feb 01 2022 at 12:53):

I was making the assumption that $member-match MUST be part of the /Patient-Access APIs as part of the Interop rule and that SMART on FHIR was in play here. Hence my question #2. After reading your responses I am not so sure. So I think this raises a few other questions to challenge those assumptions.

1. Does this have to be on the same server with SMART on FHIR as patient-access API? I think that comes down to does the individual patient need access to this or can we put this on a "separate server" for applications where I can enable different security.
2. I am suspect of using Patient.read scope, the reason I asked about it is because PDex clearly states the token ONLY gives access to $member-match which implies you cannot access Patient/*.read. I guess without a patient.id in the claim you would not be able to get any data anyway but this does not seem like the best way to do this.

Lloyd McKenzie (Feb 01 2022 at 14:22):

@Mark Scrimshire

Stephan Roorda (Feb 01 2022 at 19:48):

I think that my questions may apply to all of these operations ...

For PDex

• $pdex-everything
• $member-match

Other

• $export
• $everything

Do these have to be part of patient access APIs with SMART on FHIR? I always saw the PA APIs as for a single patient use to see their data and the above operations are all more for a different kind of access (Payer, etc)

Last updated: Apr 12 2022 at 19:14 UTC