Da Vinci Health Record Exchange (HRex)
1.0.0 - STU R1 US

This page is part of the Da Vinci Health Record Exchange (v1.0.0: STU1) based on FHIR R4. This is the current published version. For a full list of available versions, 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.0.0
Standards status: Trial-use Maturity Level: 2 Computable Name: MemberMatch

The $member-match operation 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.

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.

MemberMatch

OPERATION: MemberMatch

The official URL for this operation definition is: 

http://hl7.org/fhir/us/davinci-hrex/OperationDefinition/member-match

The $member-match operation 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.)

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

Input parameters Profile: HRex Parameters - Member Match Request Profile

Output parameters Profile: HRex Parameters - Member Match Response Profile

Parameters

UseNameCardinalityTypeBindingDocumentation
INMemberPatient1..1Resource

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

INConsent1..1Resource

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.

INCoverageToMatch1..1Resource

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.

INCoverageToLink0..1Resource

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.

OUTMemberIdentifier1..1Identifier

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

Notes:

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.

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.

Examples

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.