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

The specification should be able to assert those elements which should be MustSupport

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive
    • Icon: Highest Highest
    • US CARIN Real-time Pharmacy Benefit Check (RTPBC) (FHIR)
    • Pharmacy
    • RTPBC Coverage Profile [deprecated]
    • Profiles and Extensions
    • Hide

      Make the following adjustments to the Must Support and data population narrative in the rtpbc-coverage profile:

      • Add clarifying definitions for all of the applicable coverage-related elements: 
        • .Identifier (member ID)
        • subscriber (demographics)
        • subscriber ID (change "cardholder ID" to "subscriber ID")
        • beneficiary (patient/member demographics)
        • Coverage.class elements (rx group, rx member ID, BIN, PCN)
      • Indicate that different insurers or PBMs may require just a subset of these fields. Implementers may populate all elements for which information is available, or scope the population based the particular insurer's/PBM’s requirements
      • Clarify that a Coverage resource is not required when submitting to a pricing source. (See FHIR-25577 resolution)
      Show
      Make the following adjustments to the Must Support and data population narrative in the rtpbc-coverage profile: Add clarifying definitions for all of the applicable coverage-related elements:  .Identifier (member ID) subscriber (demographics) subscriber ID (change "cardholder ID" to "subscriber ID") beneficiary (patient/member demographics) Coverage.class elements (rx group, rx member ID, BIN, PCN) Indicate that different insurers or PBMs may require just a subset of these fields. Implementers may populate all elements for which information is available, or scope the population based the particular insurer's/PBM’s requirements Clarify that a Coverage resource is not required when submitting to a pricing source. (See FHIR-25577 resolution)
    • Scott Robertson / Pooja Babbrah : 8-0-0
    • Clarification
    • Non-substantive
    • 0.1.0

    Description

      The specification should be able to assert those elements which should be MustSupport which would then allow the users to populate those elements which are appropriate to the sender without an additional need for coordination between senders and receivers.
      The MustSupport elemets should be determined and so flagged prior to publication.

      Existing Wording:

      Due to the variability of benefit eligibility identification approaches, implementing partners MUST establish which Must Support elements pertain to their situation.

      Attachments

        Activity

          People

            Unassigned Unassigned
            pknapp Paul Knapp
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: