Da Vinci Health Record Exchange (HRex)
1.1.0-preview - STU R1 United States of America flag

Da Vinci Health Record Exchange (HRex), published by HL7 International / Clinical Interoperability Council. This guide is not an authorized publication; it is the continuous build for version 1.1.0-preview built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-ehrx/ and changes regularly. See the Directory of published versions

OperationDefinition: HRex Member Match Operation

Official URL: http://hl7.org/fhir/us/davinci-hrex/OperationDefinition/member-match Version: 1.1.0-preview
Standards status: Trial-use Maturity Level: 2 Computable Name: MemberMatch
Other Identifiers: OID:2.16.840.1.113883.4.642.

The $member-match operation that can be invoked by either a payer or an EHR or other system, allows one health plan to retrieve a unique identifier for a member from another health plan using a member’s demographic and coverage information. This identifier can then be used to perform subsequent queries and operations. Members implementing 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 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 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 identity of the member 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 payer)
  • The target payer’s Coverage information (as gleaned from the member’s card)
  • The consent of the member (or responsible party) for the member’s information held by the target payer to be shared with the requesting system

The response returns:

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

An identifier is used rather than a member id as most 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.

URL: [base]/Patient/$member-match

Input parameters Profile: HRex Parameters - Member Match Request Profile

Output parameters Profile: HRex Parameters - Member Match Response Profile



Parameter submitted by the new plan SHALL contain US Core Patient containing member demographics.


Consent held by the system seeking the match that grants permission to access the patient information information on the system for whom a patient is sought. Downstream IGs may tighten this to 'required' if necessary.


Parameter that identifies the coverage to be matched by the receiving payer. It contains the coverage details of health plan coverage provided by the member, typically from their health plan coverage card.


Parameter that identifies the coverage information of the member as they are known by the requesting payer. This information allows the matching payer to link their member coverage information to that of the requesting payer to ease subsequent exchanges, including evaluating authorization to share information in subsequent queries. This parameter is optional as this operation may be invoked by non-payer systems. However, it is considered 'mustSupport'. If the client invoking the operation is a payer, they SHALL include their coverage information for the member when invoking the operation.


This is the member identifier information for the patient as known by the server that is the target of the operation.


This is the RESTful identity for the patient as known by the server that is the target of the operation.


The response from a failed $member-match is a “422 Unprocessable Entity Status Code”.

After a successful $member-match the requesting system SHALL then use the UMB provided by the target payer in the Patient.identifier field in any subsequent transactions with the same system. If the requesting system was a payer with coverage for the member, the receiving system SHOULD create a linkage between their own member information and the Coverage provided by the requesting system. This linkage can be used to support subsequent queries by establishing a known ‘reason’ for accessing a member’s information.

NOTE: For privacy reasons, the ‘CoverageToLink’ SHOULD NOT include any data elements not marked as mustSupport in the Coverage profile.

Resolving parameter references

The input parameters include both Coverage and Consent resources with a reference to a Patient resource. Those references SHALL be ‘local’ references (i.e. starting with “Patient/” rather than “http”), SHALL be resolved to the parameter with the name “MemberPatient”, and SHALL refer to the same id.

Member matching Logic

This specification does not define the member matching logic that is used by a Payer that processes a $member-match operation. However, because matching member identity is a key step in the release of potentially sensitive patient information, the algorithms used should be robust. Servers SHALL monitor for and take measures to prevent brute force attacks where the same or similar set of demographics are repeatedly searched with differing card information in an attempt to achieve a match when the card information is unknown.

Matching behavior is:

  • A maximum of a SINGLE unique match SHALL be returned.
  • No match SHALL return a 422 status code.
  • Multiple matches SHALL return a 422 status code.
  • If consent is provided, inability to comply with consent requirements SHALL return a 422 status code

Any 422 response codes SHOULD be accompanied by an OperationOutcome that indicates the specific nature of the failure.

An important objective of this specification is to ensure that a health plan operating a $member-match operation has sufficient data provided to enable a match operation to be performed. Therefore, the specification requires a health plan to provide demographic information (name, date of birth, gender) and identification details that would be present on a member’s health plan insurance card with a request.

While logically a somewhat separate operation, the sharing of consent is piggy-backed into the matching of member information because, at least at present, Da Vinci workflows requring member matching inevitably also require the sharing of consent and performing both in a single step minimizes design complexity. It is possible that, in the future, these functions may be separated.

The member match operation allows establishing that a consent exists. It does not, however, provide a mechanism for indicating that a consent has been revoked. At present, we have not found a use-case that requires sharing of revocation information. If the consent gets revoked on the data comsumer’s side, then that system simply stops requesting information. If the consent is revoked on the data source’s side, then it simply stops sending information in response to a request. Thus, it is sufficient that revocation occurs only within one system and there is no need to transmit it to the other.

The recipient of a member match 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 during subsequent requests. This information might be stored as a Consent instance in a FHIR store, ubut use of a FHIR store is not required.


An example request (as POSTed when invoking the operation) can be found here and an example response (as received in the HTTP response body after the operation processes) can be found here.