Version 2 for Testing at Connectathon 29 (2022-01-10):
Posting to this page since we are currently unable to update the CI Build of PDex.
The steps in the Member Match with Consent process are:
- Establish a secure connection via mTLS
- Use mTLS secure connection to perform OAuth2.0 Dynamic Client Registration to acquire OAuth2.0 client credentials
- Use mTLS secure connection to perform MemberMatch operation
- The MemberMatch operation uses Patient and Coverage records to determine if a member is found
- The MemberMatch operation evaluates the Consent resource for a matched member
- If a Member is matched and the Consent request can be complied with (Per Policy request and Date range) a UNique Member Match ID is created for Payer2
- If a Member Match Id is returned from $MemberMatch a request is made to OAuth2.0 Token endpoint for an OAuth2.0 Access and Refresh Token
- If a Token is granted the requesting payer performs data retrieval steps using appropriate methods, defined below.
The $MemberMatch operation is defined in the [HRex Member Match operation](http://build.fhir.org/ig/HL7/davinci-ehrx/OperationDefinition-member-match.html) from the [Da Vinci Health Record Exchange IG](http://build.fhir.org/ig/HL7/davinci-ehrx). The profiles used in the Member Match Operation are also defined in the [HRex IG](http://build.fhir.org/ig/HL7/davinci-ehrx). These are:
- [US Core Patient Profile](http://hl7.org/fhir/us/core/STU4/StructureDefinition-us-core-patient.html)
- [HRex Coverage Profile](http://build.fhir.org/ig/HL7/davinci-ehrx/StructureDefinition-hrex-coverage.html)
- [HRex Consent Profile](http://build.fhir.org/ig/HL7/davinci-ehrx/StructureDefinition-hrex-consent.html)
In the case where a Member Match is confirmed the receiving payer will:
- Utilize the consent record to evaluate the request from the requesting payer for data about the matched member. For example, is the payer able to respond to a request for only non-sensitive data.
- Return a Unique Member Match Identifier in the Member Match Operation Response.
If the receiving payer is unable to comply with the consent request a Member Match ID is NOT returned in the $MemberMatch response/
#### Evaluation of Consent
The receiving payer **MAY** store the Consent record for the member. The following content from the Consent record
is used to validate a data request:
- Member Identity is matched
- Consent Policy (Everything or only Non-Sensitive data) matches the data release segmentation capabilities of the receiving payer
- Date period for consent is valid
- Payer requesting retrieval of data is matched
#### Data Retrieval Methods
Once Health Plans have completed the $MemberAccess stage of the Exchange the requesting Health Plan **SHALL**
utilize the access token returned from the Member Access step to request/retrieve data using one of the
following three methods:
1. Query all clinical resource individually
2. Patient/{id}/$everything-pdex operation
3. Bulk FHIR Asynchronous protocols
Version 1:
NOTE: Previously called $payer-match.
Find Member using Patient and Coverage Resources
OPERATION: Find member using search driven by member patient and coverage information
When a member switches from one plan to another the member has the option to request their data be passed to their new health plan.
The new Health Plan SHALL enable an enrolling member to provide the coverage details for their prior health plan. The new Health Plan SHALL create the following resources that will be compiled into a Parameter Resource and submitted to the $member-match operation on the Patient FHIR endpoint for the old health plan:
- US Core Patient (Containing Member demographics)
- Coverage (details of prior health plan coverage provided by the member, typically from their Health Plan coverage card)
- Coverage (details of new or prospective health plan coverage, provided by the health plan based upon the member's enrollment)
The New Health Plan Coverage record provides information for the prior Health Plan to determine the identity of their member in the new health plan, enabling them to identify the member in the new Health Plan for any future communications.
The Health Plan should enter the unique member identifier
The Old Health Plan should return the following data:
- The unique member identifier added to the Patient.identifier in the Patient resource submitted by the new health plan.
- The new health plan coverage resource.
- Only one Patient and one Coverage record are returned.
Reference Implementation Information: Member-Match Reference Implementation
Providing a directory of FHIR Endpoints that support the $member-match operation for each health plan is outside the scope of this operation.
A suggestion is that the FHIR endpoint is discoverable via a file in the .well-known folder of the URL for the health plan that is typically found on a member's health plan insurance card.
Operation:
URL: POST [base]/Patient/$member-match
Patient.identifier
When the New Health Plan creates an OldCoverage parameter where the Coverage resource has a Coverage.identifier where the identifier.type is "MB". The "MB" value is taken from the http://terminology.hl7.org/CodeSystem/v2-0203 value set.
When the Old Health Plan returns the Patient Record they SHALL ADD a Patient.identifier with the Patient.identifier.type = "UMB" (Unique Member Identifier). This is a new type value.
A code system will be created with a value set with a single entry "UMB" and will be referenced by the value set for identifier.
Note: the UMB value is a placeholder for Connectathon-24. Other potential Patient.identifier.type values that could replace UMB include PI or PT. (Feedback is welcomed on this choice).
Unique Member Identifier
The Health Plan SHALL return a unique member identifier and a corresponding system value that identifies the plan.
The member identifier SHALL be either the internal unique identifier, or an identifier that is mapped one-to-one to the Health Plan's unique member identifier.
Parameters
Use | Name | Cardinality | Type | Binding | Documentation |
|---|---|---|---|---|---|
| IN | resource | 1..1 | Parameter | Use this to provide a set of coverage and beneficiary details for the match operation to search for a unique member record (e.g. POST a parameter with Patient, Old Coverage and New Coverage to Patient/$member-match). | |
| OUT | return | 1..1 | Parameter | The returned Parameter resource will contain the New Plan's Coverage record and their Member Patient record with the ADDITION of an identifier of type "UMB" that represents the Unique identifier to identify the member records at the old health plan. If the operation failed to find a unique match then a BadRequest status code is returned. (e.g. 422 - Unprocessable Entity). |
The response from a successful $member-match is a parameter containing the updated Patient resource submitted, but with the UMB identifier, and the new health plan coverage record as submitted in the original Parameter request.
The response from a failed $member-match is a 422 Unprocessable Entity Status Code.
After a successful $member-match the new health plan will then use the unique member identifier provided by the Old Health Plan in the Patient.identifer field to query for any subsequent transactions related to payer-to-payer exchange.
For example, in PDex 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 is not attempting to define the member matching logic that is used by a Payer that processes a $member-match operation.
The specification is:
- defining that only a SINGLE unique match is returned.
- No match returns a 422 status code.
- Multiple matches returns a 422 status code.
- Defining the content passed into the $member-match operation.
- Defining the data returned from the $member-match operation.
An important objective of this specification is to ensure that a payer operating a $member-match operation has sufficient data provided to enable a match operation to be performed.
For the requesting payer the specification assumes that a new member is able to provide their demographic information (name, date of birth, gender) and the identification details that would be present on their health plan insurance card.
$member-match Parameter Example
Example request: $member-match Parameter resource submitted by the new health plan. Note the Patient identifier type set to "MB".
$member-match accepts a POST with the Parameters json bundle in the body.
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberPatient",
"resource": {
"resourceType": "Patient",
"id": "1",
"identifier": [
{
"type": {
"coding": [
{
"system": "http://hl7.davinci.org",
"code": "MB"
}
]
},
"system": "http://oldhealthplan.example.com",
"value": "55678",
"assigner": {
"reference": "Organization/2",
"_reference": {
"fhir_comments": [
"MB is passed from coverage card by new health plan."
]
}
}
}
],
"name": [
{
"use": "official",
"family": "Person",
"given": [
"Patricia",
"Ann"
]
}
],
"gender": "female",
"birthDate": "1974-12-25"
}
},
{
"name": "OldCoverage",
"resource": {
"resourceType": "Coverage",
"id": "9876B1",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">A human-readable rendering of the coverage</div>"
},
"contained": [
{
"resourceType": "Organization",
"id": "Organization/2",
"name": "Old Health Plan",
"endpoint": [
{
"reference": "http://www.oldhealthplan.com"
}
]
}
],
"identifier": [
{
"system": "http://oldhealthplan.example.com",
"value": "DH10001235"
}
],
"status": "draft",
"beneficiary": {
"reference": "Patient/4"
},
"period": {
"start": "2011-05-23",
"end": "2012-05-23"
},
"payor": [
{
"reference": "#Organization/2"
}
],
"class": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "group"
}
]
},
"value": "CB135"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "plan"
}
]
},
"value": "B37FC"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "subplan"
}
]
},
"value": "P7"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "class"
}
]
},
"value": "SILVER"
}
]
}
},
{
"name": "NewCoverage",
"resource": {
"resourceType": "Coverage",
"id": "AA87654",
"contained": [
{
"resourceType" : "Organization",
"id" : "Organization/3",
"name" : "New Health Plan",
"endpoint" : [
{
"reference" : "http://www.newhealthplan.com"
}
]
}
],
"identifier": [
{
"system": "http://newealthplan.example.com",
"value": "234567"
}
],
"status": "active",
"beneficiary": {
"reference": "Patient/1"
},
"period": {
"start": "2020-04-01",
"end": "2021-03-31"
},
"payor": [
{
"reference": "#Organization/3"
}
],
"class": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "group"
}
]
},
"value": "A55521",
"name": "New Health Plan Group"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "subgroup"
}
]
},
"value": "456"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "plan"
}
]
},
"value": "99012"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "subplan"
}
]
},
"value": "A4"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "class"
}
]
},
"value": "GOLD"
}
]
}
}
]
}
Parameter Response
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberPatient",
"resource": {
"resourceType": "Patient",
"id": "1",
"identifier": [
{
"type": {
"coding": [
{
"system": "http://hl7.davinci.org",
"code": "MB"
}
]
},
"system": "http://oldhealthplan.example.com",
"value": "55678",
"assigner": {
"reference": "Organization/2",
"_reference": {
"fhir_comments": [
"MB is passed from coverage card by new health plan."
]
}
}
},
{
"use": "usual",
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "UMB",
"display": "Member Number",
"userSelected": false
}
],
"text": "Member Number"
},
"system": "https://old.payer.example.com/diamond-health-ppo/uniquemember",
"value": "dhu-10102"
}
],
"name": [
{
"use": "official",
"family": "Person",
"given": [
"Patricia",
"Ann"
]
}
],
"gender": "female",
"birthDate": "1974-12-25"
}
},
{
"name": "NewCoverage",
"resource": {
"resourceType": "Coverage",
"id": "AA87654",
"contained": [
{
"resourceType": "Organization",
"id": "Organization/3",
"name": "New Health Plan",
"endpoint": [
{
"reference": "http://www.newhealthplan.com"
}
]
}
],
"identifier": [
{
"system": "http://newealthplan.example.com",
"value": "234567"
}
],
"status": "active",
"beneficiary": {
"reference": "Patient/1"
},
"period": {
"start": "2020-04-01",
"end": "2021-03-31"
},
"payor": [
{
"reference": "#Organization/3"
}
],
"class": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "group"
}
]
},
"value": "A55521",
"name": "New Health Plan Group"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "subgroup"
}
]
},
"value": "456"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "plan"
}
]
},
"value": "99012"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "subplan"
}
]
},
"value": "A4"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "class"
}
]
},
"value": "GOLD"
}
]
}
}
]
}
11 Comments
Michelle Barry
I appreciate the details above. What are we doing for the instances of when a beneficiary/patient might have secondary health insurance or supplemental insurance like Medigap? Are we creating a use case to further define how beneficiary/patient information will be shared from the primary health plan/payer to secondary health plan/payer? Please forgive me if this was covered already; I am unable to locate this specific use case. I would appreciate any insight and feedback for the team. Thanks
Lloyd McKenzie
Bundle type shouldn't be 'transaction'. In fact, would recommend not using a Bundle at all. Instead, use a Parameters resource, which is the general mechanism for invoking a FHIR operation with multiple arguments.
Are the "id" elements on Patient and Coverage expected to be persistent/resolvable on future calls?
May Terry
Thanks Lloyd McKenzie. I took a first pass at migrating the above example from a transaction Bundle to a Parameter resource instance. This example also passed FHIR validation for structural integrity.
Let me know if something like the attached JSON is what you had in mind.
pcde-payermatch-parameter-example.json
cc: Mark Scrimshire
Thanks! ~May
Lloyd McKenzie
I'd have probably kept the parameter names a bit shorter - "patient", "oldCoverage", "newCoverage". (HealthPlan isn't really a term in FHIR, so better to stick with standard concept names if you can). Other than that, looks good to me.
May Terry
Thanks Lloyd! I'll make the suggested edits and re-post. Mark Scrimshire - we can review the changes at the Wednesday morning PDEx working session.
Michele Mottini
The 'Parameters' table does not match the examples - it should list the name of the various parameters.
The sample request and response have an 'exact' parameter that is not explained anywhere.
I don't think it is a good idea to have the operation return 404 if there is no match: that's the code you get if the URL you used points to nothing - that is not really the case here. I'd suggest using 422 instead.
Michele Mottini
Instead of returning the identifier inside the patient resource using a special type to identify it etc. wouldn't be simpler / easier to return it as a separate parameter?
Mark Scrimshire
It would certainly be easy to return the Unique Member Id as a separate Parameter.
Michele Mottini May Terry What do you think about returning the Identifier dict from the old plan's patient record rather than just returning a value.
eg.
{"name": "uniqueMemberId",
{
"use": "usual",
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "UMB",
"display": "Member Number",
"userSelected": false
}
],
"text": "Member Number"
},
"system": "https://old.payer.example.com/diamond-health-ppo/uniquemember",
"value": "dhu-10102"
}
}
Michele Mottini
Yes, you'll need the entire identifier as the parameter value because it has both a value and a system - and you'd need both; but if the only purpose of identifier.type was to distinguish that identifier from the other ones that's no longer needed, so:
{
"name": "uniqueMemberId",
"valueIdentifier": {
"system": "https://old.payer.example.com/diamond-health-ppo/uniquemember",
"value": "dhu-10102"
}
}
May Terry
Michele Mottini - re: using 422 instead of 404. This makes sense and seems more appropriate for a return error.
Perhaps we can discuss this at the Connectathon kick-off tomorrow, May 14, at 10a ET? Since we already have some implementations that are already writing to this current behavior, it makes sense to bring up and see if they can refactor during the connectathon. cc: Mark Scrimshire
Michele Mottini
Why does the new health plan need an identifier for the patient in the old health plan? Wouldn't the (old plan) patient id be enough?