Stream: Da Vinci PDex
Topic: Should member-match update the patient record?
Caitlin Voegele (Feb 15 2022 at 15:41):
When using the member-match, is the expectation that the operation will simply provide the output with the new UMB identifier and the New Health Plan can decide what to do with the data or when the member-match finds a successful match, should it return the output and update the patient record in the new health plans system with the identifier? I interpreted the operation as simply searching/displaying data and not actually writing anything to either database, but wanted to validate that understanding.
Lloyd McKenzie (Feb 15 2022 at 15:50):
It simply returns the identifier. How/if the invoking client chooses to store the id is up to them - though adding it to their Patient record would certainly be a reasonable action to take.
Caitlin Voegele (Feb 15 2022 at 17:45):
Thanks so much! A follow up question :) I've been trying to see how the operation should work with the appended UMB and looking at the sample data I'm a bit lost.
In This example: https://hl7.org/fhir/us/davinci-hrex/2020Sep/Parameters-member-match-out.json.html the UMB value is dhu-10102. However, looking at the patient above and the example for the input here: https://hl7.org/fhir/us/davinci-hrex/2020Sep/Parameters-member-match-in.json.html I don't see anywhere that the value DHU-10102 is associated with the patient (or even the coverage information). Can you help me understand how the UMB value is populated in the output example?
Daniel Venton (Feb 15 2022 at 18:41):
PayerConsumer provides data to PayerServer in the form of a Patient and a Coverage and a Consent resources. PayerConsumer asks the question "Do you know this person and if so what is their member id?" PayerServer attempts to match the data provided to their member list, if PayerServer finds a match they return a UMB that corresponds to the identifier of the member as known by PayerServer. PayerConsumer will then ask, "Can I have an access token for {UMB}?" Which the PayerServer will recognize as an identifier of one of their members and return an access token.
Lloyd McKenzie (Feb 15 2022 at 19:55):
Right. The input doesn't contain the id. The input contains the information the target payer uses to figure out who the person is (and thus what their identifier is)
Caitlin Voegele (Feb 15 2022 at 20:23):
@Daniel Venton - In the HRex definition for Member-Match there is nothing listed currently about Consent (https://hl7.org/fhir/us/davinci-hrex/2020Sep/OperationDefinition-member-match.html). Where would the consent resource be included?
I think my question above is more about how would you get a value of DHU-10102 for UMB if that value isn't anywhere on the patient in the input example? I know it won't be the ID but would have expected it to be in the identifier field somewhere?
Is there the sample patient that works with this example available somewhere? I didn't see it in the examples. https://hl7.org/fhir/us/davinci-hrex/2020Sep/artifacts.html#example-example-instances
Daniel Venton (Feb 15 2022 at 20:36):
If the PayerConsumer already knew what the PayerServer had as the patient identifier so that they could include it in the member-match operation, then why would they need to execute the member-match operation?
Next version of pdex put the consent into the $member-match operation instead of a $memberaccess operation http://build.fhir.org/ig/HL7/davinci-epdx/PayerToPayerExchange.html
Lloyd McKenzie (Feb 15 2022 at 21:20):
Don't look at the 2020Sep version of member match - look at the CI-build version - https://build.fhir.org/ig/HL7/davinci-ehrx/OperationDefinition-member-match.html
Last updated: Apr 12 2022 at 19:14 UTC
