Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-37644

Consent revocation for P2P

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci PDex (FHIR)
    • current
    • Financial Mgmt
    • Payer-to-Payer Exchange [deprecated]
    • Hide

      Add the following guidance to the Payer-to-payer exchange page:

            1. Consent Revocation

      The following guidance is provided for a situation where a member wishes to revoke consent for a previously grannted Payer-to-payer exchange.

      As part of Payer-to-Payer Exchange Consent is gathered by the New Payer.
      Since the New Payer has the current relationship with the member it is proposed that the New Payer manages the Consent Revocation process. This would involve the New Payer cancelling any recurring request to the old payer for new information for the member.

      This approach does not preclude the member contracting their old payer and issuing a consent directive to block the release of data to the new payer. However, this is anticipated to be a rare occurrence.

      Show
      Add the following guidance to the Payer-to-payer exchange page: Consent Revocation The following guidance is provided for a situation where a member wishes to revoke consent for a previously grannted Payer-to-payer exchange. As part of Payer-to-Payer Exchange Consent is gathered by the New Payer. Since the New Payer has the current relationship with the member it is proposed that the New Payer manages the Consent Revocation process. This would involve the New Payer cancelling any recurring request to the old payer for new information for the member. This approach does not preclude the member contracting their old payer and issuing a consent directive to block the release of data to the new payer. However, this is anticipated to be a rare occurrence.
    • Bob Dieterle / Celine Lefebvre: 21-0-1
    • Clarification
    • Compatible, substantive
    • 2.0.0-ballot [deprecated]

      The step 16 of the Payer to Payer data exchange workflow reads:

      "Token endpoint matches to member using MemberMatch ID and confirms that consent is still valid"

      Consent being valid means, among others:

       - consent_start_date < current_date < consent_end_date

       - consent hasn't been revoked by the user

      Because the party verifying consent validity is the old payer, which most likely has no way to contact a former customer, how do we handle a scenario in which the customer wants to revoke it?

      Should it be responsibility of the Old payer, New payer or both?

      A first idea has been discussed, putting the onus on the New payer to flag the consent as revoked, and trusting the New payer will not request data for which it doesn't have the rights to request.

        1. Screen Shot 2022-06-22 at 11.55.08 AM.png
          Screen Shot 2022-06-22 at 11.55.08 AM.png
          29 kB

            Unassigned Unassigned
            ezekraken Ezequiel Morales
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: