With Consent included in the $member-match operation there is a situation where a member may be successfully matched but the consent request can't be complied with. For example, where a member has requested only non-sensitive be exchanged and the data holder is unable to segregate that category of data, therefore forcing them to refuse the exchange request.

In the above situation while returning a 422 status we should also issue an operation outcome that identifies that:

"Unable to comply with consent requirements"

This can be interpreted by the requesting payer that a unique match was found but the consent stipulation couldn't be complied with.

Section 11.1.2.1.3 should also provide additional guidance that an implementer should store the parameters of the consent (Validity Period, Scope etc.) to enable the authorization server to evaluate the consent before issuing a token for data access.

Note - The Implementer can store consent information in any appropriate system. Storing the FHIR Consent record in a FHIR Store is not a requirement of this guide, however it would be an option for an implementer.