Execute the Da Vinci HRex $member-match operation to correlate a member record across two payer systems and obtain consent before initiating payer-to-payer data exchange
Construct a Parameters resource with the required parameter names as defined in the HRex member-match IG: MemberPatient carrying a Patient resource representing the member's demographic data, CoverageToMatch carrying a Coverage resource representing the member's prior coverage, and CoverageToLink carrying a Coverage resource for the new payer's coverage
POST the Parameters resource to the prior payer's endpoint at the path defined in the CapabilityStatement under the MemberMatch OperationDefinition, using a SMART Backend Services access token obtained with appropriate system-level scopes
Parse the 200 response body which returns a single-parameter Parameters resource containing MemberIdentifier — a unique identifier the prior payer assigns to the matched member that must be used in all subsequent data requests
If the operation returns a 422 Unprocessable Entity, parse the OperationOutcome to determine whether the failure is due to insufficient demographics for a match, multiple possible matches, or a member who has opted out of data sharing
Before initiating any data retrieval, verify that the HRex Consent resource authorizing payer-to-payer exchange exists or obtain explicit consent by posting a Consent resource referencing the member identifier returned from $member-match
Use the matched member identifier as a patient identifier in subsequent PDex $export or individual FHIR queries to retrieve clinical and claims history from the prior payer
Known gotchas
The $member-match operation requires exact demographic matching to a confidence threshold defined by the prior payer; submitting demographics with a name mismatch of even a single character due to hyphenation or suffix differences can cause a match failure even when the member is clearly identifiable
The MemberIdentifier returned is payer-specific and not a standard identifier like MBI or insurance subscriber ID; it must be stored and passed back to the same payer for subsequent data requests and cannot be used with a different payer
A successful $member-match does not grant access to data — it only establishes identity correlation; data access rights are governed by the Consent resource and the access token scopes, and missing either will produce a 403 on subsequent data requests
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp