Can we make the member-match operation definition narrative more generic so that implementers know that the operation can be exposed and utilized by both payers and providers. Also the identifier that is received through the operation does not seem to be clearly defined. 

Suggested changes in bold and strikethrough below: 

The $member-match operation that can be invoked by either a payer or an EHR or other system, allows retrieval one health plan  to retrieve a of a FHIR Patient Logical Id unique identifier for a member from another health plan using a member’s demographic and coverage information. This identifier FHIR Patient Logical Id can then be used to perform subsequent queries and operations. Members implementing Performing a deterministic match will require a match on member id or subscriber id at a minimum (i.e. A pure demographic match will not be supported by such implementations.).

 
To access information about a member on a payer’s system, the requesting system needs to know the a unique identifier or the FHIR Patient Logical Id unique identifier of that member on the payer’s system. However, in many cases, neither the client system nor the patient will have this information. The $member-match operation supports identifying a Patient using member and coverage information to support subsequent queries and operations. the target payer’s member and coverage information for a specified member so the client can use that information for subsequent queries and operations.

In addition, the $member-match operation allows establishing consent from the patient (or other responsible party) that enables information to flow between the initiating system and the responding system.

This operation might be used by EHRs, other payers, or any other type of system that needs to interact with a payer and who needs to resolve the FHIR Patient Logical Id identity of the member patient in question on the target payer’s system.

The operation works by passing in up to four parameters:

• The requesting system’s demographic information on the member (as a Patient resource)
• If initiated by a payer holding coverage for the member, the requesting payer’s Coverage information (to allow linking by the receiving systempayer)
• The target payer’s Coverage information (as gleaned from the member’s card)
• The consent of the member patient(or responsible party) for the patientmember’s information held by the target systempayer to be shared with the requesting system

The response returns:

• The target system's FHIR Patient Logical Id payer’s identifier information on the member - their unique member identifier (UMB) sent as an Identifer within a Parameters instance.

An identifier FHIR Patient Logical Id is used rather than a member id as most systems payers do not (yet) expose RESTful ids for their member or coverage records. This identifier can be used in subsequent interactions with the target payer system.