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 4.2.2.1 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
    • • HRex Coverage Profile in section 4.2.1 of PDEX links to the HRex Patient Demographics Profile.
      • After defining the steps for Member Match with Consent process, the $MemberMatch operation is mentioned. This definition points to the HRex IG, which in turn points to the Official URL (http://hl7.org/fhir/us/davinci-hrex/OperationDefinition/member-match) . The Official URL returns a 404  

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

•  Patient/{id}/$everything-pdex links to the definition for $everything-pdex (section 12.2.1). http://hl7.org/fhir/OperationDefinition/patient-everything-pdex is identified as the Official URL for the operation definition. The Official URL returns a 404.

HREX

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

Comments:

Subsection 11.1.2

• Inside the HREX IG section 11.1.2 this link: http://hl7.org/fhir/us/davinci-hrex/OperationDefinition/member-match is identified as the official url for the operation definition. The url returns a 404.