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

Incorrect Diagram for Member match, Evaluation of Consent



    • Icon: Technical Correction Technical Correction
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • US Da Vinci PDex (FHIR)
    • 2.0.0-ballot
    • Financial Mgmt
    • HRex Coverage Profile [deprecated]
      patient-everything-pdex [deprecated]
    • (many)
    • many


      Section 0 Table of Contents

      • IF the Consent Resource will be finally used as part of the member-match operation, it should be added to the list of resources involved in this IG. It should be clarified it will not be exchanged as par of the $everything payload, but just an accessory to the member-match operation.

      Section 4.2 Payer to Payer Exchange

      Subsection 4.2.1  Member Match with Consent

      • Step 1a in the diagram for section 4.2.1 Member match with consent needs more explicit detail.  We have been discussing a GitHub repo with signed bundle of endpoints and organization resources.  This needs to be flushed out and included.
        • Question weather the implementation details belong in the IG. 
      • For the diagram in section we would propose the following an alternative data flow removing step 3.  We recommend utilizing the original token acquired in step 2a as depicted in the diagram below.
        • This approach does alleviate the need to customize and Authorization/Identity implementation.
          • Complies with standard OAuth Client Credentials (B2B) flow.
        • Complies with SMART backend services flow: HL7.FHIR.UV.SMART-APP-LAUNCH\Backend Services - FHIR v4.0.1
        • Complies with, and follows the same conventions as the SMART launch specification and SMART user/* scopes.
          • Provider example with user/* scopes:  a provider has access to 10% of the patient population.  Access to a set of patients, not all and not 1.  This is another case where the FHIR server not the Auth server will be involved in downscoping.
        • This approach reduces the tokens from 2 per member-match transaction to 1 (potential licensing cost reduction depending on AuthZ/AuthN provider)
        • The FHIR server is being updated to handle both the $member-match and the $everything-pdex operations having the $everything-pdex operation check consent seems like a natural part of the operation
          • If we get rid of the $everything-pdex operation this point is no longer valid

      Subsection 4.2.2 Evaluation of Consent

      • "If a Consent is provided by an Authorized Representative the person's demographic details should be included as a contained resource (such as Patient or RelatedPerson) within the consent record. The Authorized Representative should be identified as an actor with an appropriate SecurityRoleType, such as "DPOWATT", "HPOWATT" or similar value."
      • Based on CMS FAQs we understand that P2P is a CE-to-CE transaction and hence the old payer does not 
        • need to know who requested this exchange
        • under what authority and
        • perform any checks to confirm their access to that data
          Based on our discussions so far we understand that DaVinci has submitted a question to CMS to get further clarifications on this scenario. This means this section of the IG is not based on any clear guidelines. And until we get the clarity we should assume that there is no requirement to include the Authorized Rep's demographic details in the request and no need for an old payer to evaluate the same. It would help simplify the solution.

      Subsection 4.2.5 Patient/{id}/$everything-pdex operation


      IG Reference: HL7.FHIR.US.DAVINCI-HREX\Home - FHIR v4.0.1


      Subsection 11.1.2





            ekivemark Mark Scrimshire
            jason.teeple Jason Teeple
            2 Start watching this issue