Da Vinci Health Record Exchange (HRex)
0.2.0 - STU R1 - 2nd ballot

Da Vinci Health Record Exchange (HRex), published by HL7 International - Clinical Interoperability Council. This is not an authorized publication; it is the continuous build for version 0.2.0). 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

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.

The operation works by passing in three sets of information:

  • The requesting payer’s demographic information on the member (as a Patient resource)
  • The requesting payer’s Coverage information (as justification/support for the matching request)
  • The target payer’s Coverage information (as gleaned from the member’s card)

The response returns:

  • The target payer’s demographic information on the member - including their unique member identifier (UMB) sent as one of the Patient.identifier repetitions
  • The target payer’s Coverage information (as officially known to the payer)

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.

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INMemberPatient1..1Resource

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

INOldCoverage1..1Resource

Parameter submitted by the new plan SHALL contain Coverage details of prior health plan coverage provided by the member, typically from their health plan coverage card.

INNewCoverage1..1Resource

Parameter submitted by the new plan SHALL contain Coverage details of new or prospective health plan coverage provided by the new health plan based upon the member's enrollment.

OUTMemberPatient1..1Resource

Parameter returned by the old plan resource SHALL contain the MemberPatient resource received from new plan with the ADDITION of an identifier of type "UMB" representing the unique identifier identifying the member of the old health plan.

OUTNewCoverage1..1Resource

Parameter returned by the old plan resource SHALL contain the NewCoverage record received from the new plan.

Notes:

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

After a successful $member-match the new health plan SHALL then use the UMB provided by the old health plan in the Patient.identifier field in any subsequent transactions related to payer-to-payer exchange.

For example, in the Da Vinci PDex IG, the new health plan will subsequently use the UMB identifier to request the member’s health records. This can be done by querying the US Core FHIR profile endpoints which will be constrained to the identified member. Alternatively, the new health plan can perform a $everything operation to the Patient/{ID}/$everything operation endpoint to receive a bundle of the member’s health records.

For PCDE, the new health plan will subsequently use the UMB identifier to send a Task message and request the PCDE coverage transition bundle.

Member matching Logic

This specification does not define the member matching logic that is used by a Payer that processes a $member-match operation.

The specification is:

  • Only 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.

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.