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.).

The primary identifier of the insured and the coverage

NOTE: This HRex SearchParameter definition extends the usage context of the capabilitystatement-expectation extension to formally express implementer expectations for these elements:

• multipleAnd

• multipleOr

• modifier

• comparator

• chain

Retrieve coverages for a patient

NOTE: This HRex SearchParameter definition extends the usage context of the capabilitystatement-expectation extension to formally express implementer expectations for these elements:

• multipleAnd

• multipleOr

• modifier

• comparator

• chain

The identity of the insurer or party paying for services

NOTE: This HRex SearchParameter definition extends the usage context of the capabilitystatement-expectation extension to formally express implementer expectations for these elements:

• multipleAnd

• multipleOr

• modifier

• comparator

• chain

Reference to the subscriber

NOTE: This HRex SearchParameter definition extends the usage context of the capabilitystatement-expectation extension to formally express implementer expectations for these elements:

• multipleAnd

• multipleOr

• modifier

• comparator

• chain

ID assigned to the subscriber

NOTE: This HRex SearchParameter definition extends the usage context of the capabilitystatement-expectation extension to formally express implementer expectations for these elements:

• multipleAnd

• multipleOr

• modifier

• comparator

• chain

Target Reference(s) (usually version specific)

NOTE: This HRex SearchParameter definition extends the usage context of the capabilitystatement-expectation extension to formally express implementer expectations for these elements:

• multipleAnd

• multipleOr

• modifier

• comparator

• chain

Definition of the content of the Da Vinci .well-known endpoint

The HRex Consent Profile defines the constraints for representing a member's consent to the sharing of their healthcare information to other organizations.

The HRex Coverage Profile defines the constraints for representing a member's healthcare insurance information to the Payer for member match purposes. Coverage instances complying with this profile, sometimes together with the Patient which this profile references via beneficiary, allows a payer to identify a member in their system. It aligns with the equivalent US Core profile, but diverges in that it does not require Patient.identifier for the beneficiary.

Defines constraints on the patient resource for transmission of minimal demographic information needed for $member-match.

Additional Da Vinci constraints on organization - to represent either provider organizations or payers

The Parameters profile for Da Vinci Find Member using Patient and Coverage Resources Request. The resource must contain:

• MemberPatient - HRex Patient containing member demographics
• CoverageToMatch - details of prior health plan coverage provided by the member, typically from their health plan coverage card
• CoverageToLink - details of new or prospective health plan coverage, provided by the health plan based upon the member's enrollment

The Parameters profile for Da Vinci Find Member using Identifier datatype Response. The old health plan SHALL return the following data if records for member are found:

• The unique member identifier (denoted through identifier parameter) submitted by the new health plan.

Constraints on the US Core PractitionerRole requiring the use of Da Vinci Organization and Practitioner

This profile specifies constraints on ClaimResponse resource to reflect the contents of a pro-active prior authorization returned via a card

Additional constraints on US Core Provenance to ensure it meets payer needs, including indicating when the event occurred and retaining signatures if present

This Task profile is used to solicit information from a system when direct query is not possible and human intervention might be required

This HRex Reference Profile is intended to be used by Da Vinci IGs where there is no expectation for a RESTful reference, but there is a need for a business identifier (and possibly a display name).

An Identifier requiring both system and value

This HRex Reference Profile is intended to be used by Da Vinci IGs where there is a need for the reference to be resolvable via REST (and potentially chained through).

The date/period by which the item that is pre-authorized must be completed.

The specific provider who has been authorized to provide this item.

The location of the Da Vinci endpoint .well-known file associated with this Coverage instance. This file will define a variety of endpoints and other information pertinant to data sharing related to the coverage.

Uniquely identifies this claim item. (2000F-TRN)

The date when this item's preauthorization was issued.

The set of policy URIs for use in HRex data disclosure consent assertions

Adds 'unknown' to the list of standard coverage relationship types

The set of endpoint names (and possibly other properties) that can be defined in a Da Vinci .well-known file

The set of task codes allowed for use in HRex data request tasks

Codes temporarily defined as part of the HRex implementation guide. These will eventually migrate into an officially maintained terminology (likely HL7's UTG code systems).

A mapping between the US Core 3.1.1 and 6.1.0 PractitionerRole.code value sets

A mapping between the US Core 3.1.1 and 6.1.0 PractitionerRole.code value sets

A Parameters instance showing what the result of a $member-match operation would look like when initiated by a payer system

A Parameters instance showing what the input to the $member-match operation would look like when initiated by a payer system

A Parameters instance showing what the input to the $member-match operation would look like when initiated by a provider system

An example showing a fully populated HRex Coverage instance

An example showing a minimally populated HRex Coverage instance

An example showing a fully populated HRex Organization provider instance

An example showing a minimally populated HRex Organization provider instance

An example showing a fully populated HRex PractitionerRole instance

An example showing a minimally populated HRex PractitionerRole instance

An example showing a fully populated HRex Provenance instance

An example showing a minimally populated HRex Provenance instance

An example showing a 'code' data request task once it has results - as references to the relevant documents

An example showing a 'query' data request task once it has results - as a contained searchset Bundle

An example showing the initial view of a 'query' data request

An example showing a 'query' data request task after it has been accepted and is showing a 'progress' status

An example showing the subscription notification for a 'document' data request task that includes data

An example showing the subscription notification for a 'query' data request task that includes data

An example showing a minimally populated HRex Task Data Request instance

An example showing a polling response monitoring a completed 'document' task

Example of an unsolicited prior authorization

An example of the sort of content that would be found at [base]/.well-known/davinci-configuration

The HRex Task Update Subscription Topic allows for monitoring for newly created tasks as well as updates to assigned or requested tasks. For example, when the status changes from “in-progress” to "completed".