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)
  • 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 response returns:

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

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.

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.

For example, in the Da Vinci PDex IG, the requesting system 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 requesting 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 requesting system will subsequently use the UMB identifier to send a Task message and request the PCDE coverage transition bundle.

Similarly provider systems that initiate a member match can use the UMB in subsequent queries to access payer-held clinical and other 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 a Coverage resource with a reference to a Patient resource. That reference SHALL be a ‘local’ reference (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.

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.

If a match is successful, the server SHALL return just the member identifier information for the patient.

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.