XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci Patient Cost Transparency (PCT) (FHIR)
    • 0.1.0 [deprecated]
    • Financial Mgmt
    • STU
    • Use Case and Actors
    • 1.1, 2.1, 2.2
    • Hide

      Will update use case diagrams to represent the updated workflow diagram and the move to the async pattern for $gfe-submit. 

      Show
      Will update use case diagrams to represent the updated workflow diagram and the move to the async pattern for $gfe-submit. 
    • Rick Geimer/Paul Knapp: 9-0-1
    • Enhancement
    • Non-compatible

    Description

      The flows in section 2 generally do not reflect a clear process and the corresponding expectations for transmission of GFEs from providers to payers, transmission of Advanced EOBs from payers to members, and (optionally) transmission of Advanced EOBs from payers to providers.The flows in section 2 generally do not reflect a clear process and the corresponding expectations for transmission of GFEs from providers to payers, transmission of Advanced EOBs from payers to members, and (optionally) transmission of Advanced EOBs from payers to providers.

      For example:- The transaction documenting receipt of a gfe-submit from a provider by the payer are poorly defined and ambiguously combined with the receipt of a full AEOB- There is no clear mechanism or expectations around how the provider will receive the advanced eob from payers who support that approach- There is no FHIR based method by which the payer can notify the member that their Advanced EOB has been completed- Members (or their third-party apps) do not have access to the transaction IDs that are anticipated in the proposed polling-based approach to access advanced EOBs via FHIR. In the existing claims process, there are both payer and provider based claim numbers and these are strictly for internal use by providers and payers. Provider, payers, and members do not typically search based on transaction ID.
      Revise all flows to reflect a workflow like the one below which mimics the current X12/EOB workflows.

      1.  Convening provider/ facility SHALL submit a GFE bundle, GFE bundle id and GFEs for each co-provider / facility with an identifier equivalent to the X12 Patient Control Number to the Payer.  Bundle and Claim Profiles

      2.  The Payer assigns its claim number and optionally its own bundle id upon acceptance into the adjudication system. It SHOULD be reported back in the acceptance report (analogous to X12 277HCCA or proprietary report).  The new FHIR acceptance transaction includes the X12 Patient Control Number equivalent; i.e., the GFE bundle id. Define a FHIR transaction to provide this.           

      a.  In the current X12 world, the provider can check claim status to obtain the claim number or wait for the 835 equivalent.  This would be a SHOULD requirement for the GFE.  Define a FHIR transaction to allow this.  

      3.  The Payer adjudicates the GFEs, resulting in AEOBs.

      4.  The payer will provide an AEOB to the member electronically or via US mail.  The payer MAY provide the data through the Patient Access API (based on an updated CARIN BB FHIR transaction.)  The payer does not provide the Patient Control Number to the patient. CARIN BB IG or Bundle / EOB profile. 

      5.  The payer SHOULD submit an equivalent of the 835 to the Convening provider / facility, including its claim(s) and bundle id. Bundle and ClaimResponse Profiles

      Attachments

        Activity

          People

            rgeimer Rick Geimer
            sundine Sam Undine (Inactive)
            Patricia Taylor, Sam Undine (Inactive)
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: