Preamble

Hi. The following was raised as a question during today's conference call, and I'm filing a ticket as requested because it hasn't been previously considered. I have submitted as a Change Request because I anticipate some change to the specification; however, I'm not entirely certain what that change may look like. We can downgrade this to a Question or Comment as appropriate.

Context

Please refer to the Member Match with Consent diagram of 5.2.1, specifically:

• Step 2b: 14
• Step 3: 16

In Step 2b: 14, Old Payer either stores or computes the Consent provided with the $MemberMatch request. Note "This information will be need to be checked when Access Token is issued in Step 3".

In Step 3: 16, Old Payer's "Token endpoint matches to member using Member Identifier and confirms that consent is still valid".

Primary Concern

At Step 3: 16, the Old Payer knows the client ID and the Member Identifier; however, it does not know which Consent (whether stored or computed) should apply to this new session.

There's an implication that the initial $MemberMatch request should inform some context for a subsequent session using both the client ID and Member Identifier, and this context seems incomplete without some way of re-associating the original Consent with this new session.

A given member may have multiple Consents for a given New Payer, multiple Consents across multiple new Payers, and perhaps multiple Consents where some are provided by the member themselves and others are provided by an Authorized Representative. Simply scoping the new session to the Patient seems insufficient; this should happen with respect to a specific Consent that is known to both New and Old Payers following a given invocation of the $MemberMatch operation.

Call to Action

Provided only the client ID and Member Identifier, how is the Old Payer expected to reconcile a new appropriately scoped session with one of possibly many Consents on record?

From an implementer's perspective, I think this needs to be addressed in the specification to ensure we can interoperate across this integration point.

Possible Solutions

• Modify the response to $MemberMatch such that it returns an opaque identifier that is unique to a given invocation, which can be mapped internally by the Old Payer to a given client ID, member, and Consent.
  • This is problematic because $MemberMatch is defined in HRex, and the operation is expected to be applied to other use cases; presumably, with different expectations regarding the provided Consent.
• Modify the access request in Step 3: 16 to include both the Member Identifier and a Consent identifier.
  • This is already problematic because we are presumably using member data in a URL param, and this will only compound such concerns (see FHIR-38666 for additional questions/concerns related to this part of the workflow).
• Something else...?

Thank you!