FHIR Chat · member-match... Unique Member Match ID vs UMB · Da Vinci PDex

Stream: Da Vinci PDex

Topic: member-match... Unique Member Match ID vs UMB

---

Frank McKinney (Jan 18 2022 at 17:58):

(Tagging @Mark Scrimshire because I think this was tested in the Connectathon this month)

In the updated PDex Member Match with Consent spec, it describes the Unique MemberMatch ID returned by the old payer as being created specifically for the requesting payer…
- If a Member is matched and the Consent request can be complied with (Per Policy request and Date range) a Unique MemberMatch ID is created for the requesting Payer (Payer2)

A few (hopefully quick) questions:

• Just to confirm: the old payer creates a new Unique Member Match ID for each requesting payer (versus always returning the same member ID to all requesting payers)?
• Is the Unique Member Match ID above the same thing that was previously referred to as the UMB / Unique Member ID? Did the earlier member-match also expect that the returned UMB be unique to the requesting payer, or is that a new aspect in the new version of the operation?
• Is the Unique Member Match ID returned by the member match expected to be valid forever, or might it be usable for only a limited amount of time?
• Is part of the reason for having the old payer create a unique member ID value specifically for the requesting payer so that it can be used as sort of an authorization input in the following OAUTH step?

This might have been covered in another thread, but I couldn't find it. Feel free to point me in that direction if so.
Thanks!

Daniel Venton (Jan 18 2022 at 21:13):

During the connectathon I never figured out why there was an expectation that the value returned be a unique id other than "You might return the value of the stored Consent resource as your Unique ID, so that on the subsequent request you can link directly to the consent to get the patient.id value". I personally think returning the patient.id value works. In my opinion, it's up to the server to determine what value to return so that the server has what it needs to make the token (allowing access to patient) later.

I might want to do that, but I don't think the IG needs to specify how it works. It could be a whole lot more generic and say return a patient id value, used to get a token for member's data access.

Lloyd McKenzie (Jan 19 2022 at 05:21):

• There's no intention that the member match id for each requesting payer be different. I guess it's theoretically possible, but it would be better if it was the same id for everyone (and the same id used internally by the source payer).
• The UMB and Unique Member Match ID are one and the same
• It should ideally be valid forever. It definitely needs to be valid for a couple of years
• The member id doesn't provide authentication, it merely provides a confirmed member identity.

Frank McKinney (Jan 19 2022 at 16:46):

Thanks @Lloyd McKenzie for the clarification.

In that case, I think I'd suggest refining the wording in the STU2 PDex Member Match with Consent section, where it includes the following (where Payer 2 is the new payer initiating the member match against the member's previous payer)...
"16. Creates Unique (to Payer 2) MemberMatch ID and returns in response" and "Payer 2 receives the Unique MemberMatch ID that is unique to Payer 2" in the sequence diagram
and
"- If a Member is matched and the Consent request can be complied with (Per Policy request and Date range) a Unique MemberMatch ID is created for the requesting Payer (Payer2)" in the bulleted steps below the diagram.

That wording really suggests that the returned MemberMatch ID isn't just the responding payer's own Unique Member ID for the patient.

In the STU1 PDex guide it characterizes the UMB as
"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."
... which to me sounds more like the responding payer could return its own Unique Member ID (e.g. that it thinks of as the "MB" type from the v2 identifier type code system)... though I wasn't sure whether the phrase "This is a new type value" indicated that that that wasn't the case.

Another question that might help share my uncertainty... If I'm the new payer and I receive a UMB / Unique MemberMatch ID from the member's previous payer, would it be reasonable for me to capture that in my system as an Identifier with a type of "MB"/Unique Member ID from the V2 identifier type code system and an assigner that refers to the previous payer? Or is it a different kind of animal and MB wouldn't be an appropriate identifier type?

Thanks again for your help with this!

Lloyd McKenzie (Jan 20 2022 at 02:19):

@Mark Scrimshire

Mark Scrimshire (Jan 21 2022 at 15:23):

@Frank McKinney Answering your questions in reverse order:
4.- Is part of the reason for having the old payer create a unique member ID value specifically for the requesting payer so that it can be used as sort of an authorization input in the following OAUTH step?
Yes. The id is passed to the following auth step.

3. • Is the Unique Member Match ID returned by the member match expected to be valid forever, or might it be usable for only a limited amount of time?
     it would be valid for that payer for a limited period of time.
4. • Is the Unique Member Match ID above the same thing that was previously referred to as the UMB / Unique Member ID? Did the earlier member-match also expect that the returned UMB be unique to the requesting payer, or is that a new aspect in the new version of the operation?
     Yes - the unique member match id replaces the UMB. The original member match returned a patient record that included the UMB. The updated member match just returns the number.
5. • Just to confirm: the old payer creates a new Unique Member Match ID for each requesting payer (versus always returning the same member ID to all requesting payers)?
     Yes.

My team in testing this found that if you stored the consent for a successful match in Member Match then the Unique ID of the consent resource would meet the requirements for the unique ID and would also make it easier to evaluate a subsequent request using the unique id. For example, when a subsequent request for a token occurs after the consent end date in the consent record. The Consent record would also have the necessary links to the Requesting Payer and the target member.

We are not making it a requirement to write a consent record as part of the spec because Different payers may have other mechanisms, such as in their MDM platform, to validate requests and manage member ids.

Frank McKinney (Jan 21 2022 at 16:32):

Thanks Mark! That answered my questions

Lloyd McKenzie (Jan 21 2022 at 23:18):

@Mark Scrimshire - we should talk, because your understanding of the operation and what I'm writing in HRex are evidently not the same.

---

Last updated: Apr 12 2022 at 19:14 UTC