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

Clients & Servers need a way to know which Payer Insurance Plan InsurancePlan.plan entries (plans) a member has access to

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci Drug Formulary (FHIR)
    • 2.0.1
    • Pharmacy
    • Payer Insurance Plan
    • Queries
    • 5.1
    • Hide

      Will review the US Core Coverage (6.1.0) and the CARIN BB coverage profiles to see if they address the need, and if not add a new profile on Coverage that requires Coverage to have a class of plan and a value of the identifier in InsurancePlan.plan, as well as two cross version extensions on Coverage replicating Coverage.insurancePlan in R4 and one that adds an optional identifier extension to Coverage.class (value in R4 is string not identifier).

      Will add a constraint on PayerInsurancePlan.plan:drug-plan.identifier making it must-support so that it can be referenced from Coverage.class.value (and the new valueIdentifier extension)

      Will update the narrative on the authenticated workflow page to describe this linking mechanism.

      Will update the narrative text to note that this solution will require multiple Coverage resources on a given FHIR server even though in the real world there may be a single plan that covers all situations, one for drug coverages and another for everything else, and that the current solution will be revisited for FHIR R6. 

      Show
      Will review the US Core Coverage (6.1.0) and the CARIN BB coverage profiles to see if they address the need, and if not add a new profile on Coverage that requires Coverage to have a class of plan and a value of the identifier in InsurancePlan.plan, as well as two cross version extensions on Coverage replicating Coverage.insurancePlan in R4 and one that adds an optional identifier extension to Coverage.class (value in R4 is string not identifier). Will add a constraint on PayerInsurancePlan.plan:drug-plan.identifier making it must-support so that it can be referenced from Coverage.class.value (and the new valueIdentifier extension) Will update the narrative on the authenticated workflow page to describe this linking mechanism. Will update the narrative text to note that this solution will require multiple Coverage resources on a given FHIR server even though in the real world there may be a single plan that covers all situations, one for drug coverages and another for everything else, and that the current solution will be revisited for FHIR R6. 

      The Authenticated API access method described in the 3.3.1 Authenticated section of the PDex US Drug Formulary 2.0.1 - STU2 Use Cases and Overview page appears to indicate that authenticated API query responses should limit the set of InsurancePlan resources returned to only "the overall plan or plans that the individual is a member of"/only "the plans the authenticated member has access to in relation to their membership".  However, given the fact that the InsurancePlan resource profiled by Payer Insurance Plan is at the insurance "product" grain vs. the "plan" grain, and the 1..* cardinality of the Payer Insurance Plan InsurancePlan.plan element, how would a PDex Drug Formulary client (or FHIR only server) know which InsurancePlan.plan entry or entries the individual "is a member of"?   It seems like both clients and servers would benefit from the incorporation of a profile on the Coverage resource & an enhancement to the Payer Insurance Plan profile (e.g., InsurnacePlan.plan:drug-plan.identifier 1..) to bridge the gap between authenticated user and the InsurancePlan.plan{*} entry or entries that individual "is a member of" or "has access to in relation to their membership".

            Unassigned Unassigned
            davidriddle68@gmail.com DavidRiddle
            DavidRiddle
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: