Stream: Da Vinci PDex
Topic: member-match
Caitlin Voegele (Mar 22 2021 at 23:22):
I'm trying to understand where member-match comes into play in the CMS mandate. Is it required for the Patient Access API or does it really come into play for Payer-to-Payer? Reading through it, it seems more like Payer-to-Payer to me but wanted to make sure I wasn't missing its application in the PAtient Access API scenario.
Paul Church (Mar 23 2021 at 15:24):
As far as I understand it only applies for payer-to-payer. In the patient access case the auth server will establish the identity of the member directly.
Caitlin Voegele (Mar 24 2021 at 23:29):
Another question on member-match. Besides returning the patient.identifier, does the member-match operation write the newCoverage into the old plans' FHIR server. If not, what is the purpose of passing in newCoverage?
Also, is there any restraint to prevent you from calling member-match multiple times for the FHIR server? Where the identifier would then be stored against the patient in the new plan multiple times.
And final question, we are assuming you would want to pull in the Patient _id from the old plan into the new plan. Is that correct?
Lloyd McKenzie (Mar 25 2021 at 00:45):
It's not required to, but it can - and that's the purpose. I.e. it allows the old plan to establish a linkage to the new plan.
Nothing prohibits calling it multiple times - communication errors might prevent the new plan from storing the result in some cases and it would need to re-try. In theory, certain new payer clients might not have persistence to store the linkage. If a client calls the request multiple times, it's the responsibility of each participant to not store linkages multiple times. If you think that needs to be clarified in the spec, you can submit a change request.
The Patient id is going to be needed for subsequent operations. So it certainly should be stored.
Josh Mandel (Mar 25 2021 at 00:59):
I'm reading http://build.fhir.org/ig/HL7/davinci-ehrx/StructureDefinition-hrex-parameters-member-match-in.html for the first time -- is this the right document?
Josh Mandel (Mar 25 2021 at 01:01):
In examples like http://build.fhir.org/ig/HL7/davinci-ehrx/Parameters-member-match-in.json.html there are some surprising things, like;
- contained resources within the input parameters (like, for an organization) -- these Organizations can (and therefore should?) be fully identified and represented with regular resources
- relative references with no Bundle and no base server to resolve against (e.g.,
Patient/1) -- is the expectation that this will resolve to sibling Parameters just based on some combination or resource type and ID? FHIR doesn't define resolution semantics like this anywhere. Is there a reason Bundles aren't used if cross-resource references are required in this use case?
Josh Mandel (Mar 25 2021 at 01:03):
- http://build.fhir.org/ig/HL7/davinci-ehrx/OperationDefinition-member-match.json.html doesn't seem to impose any constraints on the parameter values other than "is a FHIR resource" -- is there a missing
targetProfile?
Josh Mandel (Mar 25 2021 at 01:05):
- http://build.fhir.org/ig/HL7/davinci-ehrx/OperationDefinition-member-match.html#membermatch says the output is "Parameter returned by the old plan resource SHALL contain the NewCoverage record received from the new plan." -- i.e., the "old" plan needs to return its
NewCoverageinput parameter unmodified as aNewCoverageoutput parameter? What is the purpose of this?
Caitlin Voegele (Mar 25 2021 at 02:06):
@Josh Mandel - I've been referencing the Operation definition on PDex here: http://hl7.org/fhir/us/davinci-hrex/2020Sep/OperationDefinition-member-match.html
Lloyd McKenzie (Mar 25 2021 at 02:07):
The contained organizations won't be in the examples anymore. Not sure anyone raised the issue w/ relative references. The presumption was that the relative references would be from the server the response came from, but if you don't think that's legit, submit a change request. The targetProfile is defined, if it's not referenced, that's an error. Pleas submit a change request.
The returning of the new plan shouldn't have been there. It was there because those involved in the connectathon weren't sure how to retain context if the member match ended up being asynchronous in batch, but there are formal FHIR-defined ways to do that and there's agreement that it shouldn't have been there. However, given that this version of the IG was referenced in regs, we can't ditch the 'SHALL' now. So what we're saying is that it SHALL be returned but we may yank that requirement in the future and clients shouldn't depend on it.
Josh Mandel (Mar 25 2021 at 02:11):
- Also just seeing the advice about returning the same Patient with new Identifiers spliced in -- if the goal is to return 1 or more new Identifier, these should be discrete output params so the recipient doesn't have to tease out the diffs.
Josh Mandel (Mar 25 2021 at 02:11):
I can file tracker items for these, but I'm confused about the "given that this version of the IG was referenced in regs, we can't ditch the 'SHALL' now" comment -- is there a published STU, and what is the regulatory reference?
Josh Mandel (Mar 25 2021 at 02:20):
Submitted FHIR-31616, FHIR-31617, FHIR-31618, FHIR-31619
Josh Mandel (Mar 25 2021 at 02:21):
There are still serious questions about authentication here, though. To @Isaac Vetter's earlier point, it's not clear how a caller would be authorized to issue this call. It's also not clear from a privacy perspective why a caller would be supplying new data to the old payer int he form of the NewCoverage input.
Josh Mandel (Mar 25 2021 at 02:24):
Added FHIR-31620 for this point.
Lloyd McKenzie (Mar 25 2021 at 02:42):
Yes, there's a published IG. Reference is in the not yet final CMS final rule that's under review by the new administration. @Robert Dieterle can provide the specific reference.
Purpose of the NewCoverage is to show reason for access and also to allow the old payer to establish a link to the new coverage.
Josh Mandel (Mar 25 2021 at 02:50):
http://hl7.org/fhir/us/davinci-hrex/history.html isn't showing me a published IG -- maybe in-process?
Josh Mandel (Mar 25 2021 at 02:51):
Purpose of the NewCoverage is to show reason for access
I'm not buying the idea that I need to tell you a pile of facts about a patient's new insurance plan to convey "I'm asking you for details about the old plan because I'm authorized to ask you for details about the old plan". What business does the old payer have "establishing a link" to the new coverage?
Lloyd McKenzie (Mar 25 2021 at 03:37):
HRex isn't published. PDex is. That's where the operation was originally defined. We're moving it out of PDex and into HRex because it's also used by PCDE.
Josh Mandel (Mar 25 2021 at 03:38):
Ah. I need to get better at these acronyms ;) does "moving" imply "no opportunity for changes"?
Lloyd McKenzie (Mar 25 2021 at 03:39):
I'll be honest and say that I don't really understand the use-case for the linking. I pushed back some and was assured it was necessary. Feel free to probe more deeply...
Abhishek (Jun 18 2021 at 14:43):
Two questions:
-
Is it understood that this operation must be offered for payer to payer? I know PDEX says "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...", but not sure if that is to say if the $member-match operation is offered, those things shall be done or if $member-match shall be offered
-
Is there a need for it if the mechanism shown in the payer to payer diagram here http://hl7.org/fhir/us/davinci-pdex/STU1/PDexImplementationActorsInteractionsDataPayloadsandMethods.html#oauth20-and-fhir-api is followed? Shouldn't the access token contain patient id info for subsequent calls?
Lloyd McKenzie (Jun 24 2021 at 20:49):
I think the intention is that $member-match SHALL be offered. However, that's not made clear in the CapabilityStatement. Can you submit a change request @Abhishek for us to clarify?
Abhishek (Jul 01 2021 at 00:47):
Thanks for the clarification @Lloyd McKenzie and sure thing, if you can direct me on how to do that
Last updated: Apr 12 2022 at 19:14 UTC
