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

Without a defined enumerated list it will be quite costly and will cause additional time to solution for the VHA to have a plug-and-play solution. - CRD #36

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci CRD (FHIR)
    • STU3
    • Financial Mgmt
    • (NA)
    • 3.2.3.1
    • Hide

      We will define an extensible binding that includes the following concepts:

      • coverage - is the therapy covered or not or are there limitations
      • prior-auth - is prior authorization required or not (and possibly provision of unsolicited prior authorizations)
      • dtr-clin - indication that DTR is relevant for prior authorization, claim or other documentation requirements and that at least some clinical information needs to be captured
      • dtr-admin - indication that DTR is relevant for prior authorization, claim or other documentation requirements and that all information to be captured is strictly administrative (and thus it is not necessary that the app be launched by the ordering clinician)
      • claim - information about what steps need to be taken to submit a claim for the service
      • insurance - allows a provider to update the patient's coverage information with additional details from the payer (e.g. expiry date, coverage extensions)
      • limits - messages warning about the patient approaching or exceeding their limits for a particular type of coverage or expiry date for coverage in general
      • network - providing information about in-network providers that could deliver the order (or in-network alternatives for an order directed out-of-network)
      • appropriate-use - guidance on whether appropriate-use documentation is needed
      • cost - what is the anticipated cost to the patient based on their coverage
      • therapy-alternatives-opt - are there alternative therapies that have better coverage and/or are lower-cost for the patient
      • therapy-alternatives-req - are there alternative therapies that must be tried first prior to coverage being available for the proposed therapy
      • clinical-reminder - reminders that a patient is due for certain screening or other therapy (based on payer recorded date of last intervention)
      • duplicate-therapy - notice that the proposed intervention has already recently occurred with a different provider when that information isn't already available in the provider system
      • contraindication - notice that the proposed intervention may be contraindicated based on information the payer has in their record that the provider doesn't have in theirs
      • guideline - indication that there is a guideline available for the proposed therapy (with an option to view)
      • off-guideline - notice that the proposed therapy may be contrary to best-practice guidelines, typically with an option to view the relevant guideline
      Show
      We will define an extensible binding that includes the following concepts: coverage - is the therapy covered or not or are there limitations prior-auth - is prior authorization required or not (and possibly provision of unsolicited prior authorizations) dtr-clin - indication that DTR is relevant for prior authorization, claim or other documentation requirements and that at least some clinical information needs to be captured dtr-admin - indication that DTR is relevant for prior authorization, claim or other documentation requirements and that all information to be captured is strictly administrative (and thus it is not necessary that the app be launched by the ordering clinician) claim - information about what steps need to be taken to submit a claim for the service insurance - allows a provider to update the patient's coverage information with additional details from the payer (e.g. expiry date, coverage extensions) limits - messages warning about the patient approaching or exceeding their limits for a particular type of coverage or expiry date for coverage in general network - providing information about in-network providers that could deliver the order (or in-network alternatives for an order directed out-of-network) appropriate-use - guidance on whether appropriate-use documentation is needed cost - what is the anticipated cost to the patient based on their coverage therapy-alternatives-opt - are there alternative therapies that have better coverage and/or are lower-cost for the patient therapy-alternatives-req - are there alternative therapies that must be tried first prior to coverage being available for the proposed therapy clinical-reminder - reminders that a patient is due for certain screening or other therapy (based on payer recorded date of last intervention) duplicate-therapy - notice that the proposed intervention has already recently occurred with a different provider when that information isn't already available in the provider system contraindication  - notice that the proposed intervention may be contraindicated based on information the payer has in their record that the provider doesn't have in theirs guideline - indication that there is a guideline available for the proposed therapy (with an option to view) off-guideline  - notice that the proposed therapy may be contrary to best-practice guidelines, typically with an option to view the relevant guideline
    • Bob Dieterle / Celine Lefebvre: 19-0-3
    • Enhancement
    • Non-compatible

    Description

      Existing Wording: This version of the implementation guide is not proposing to standardize the codes, names, types or descriptions for payer response types. This is something that could be considered for future implementation guides once it is clear what groupings of response types are useful to enable/disable together - and which response types should be configurable at all once it is clear what groupings of response types are useful to enable/disable together - and which response types should be configurable at all

      Proposed Wording: This version of the implementation guide is not proposing to standardize the codes, names, types or descriptions for payer response types. This will be proposed for future implementation guides once it is clear what groupings of response types are useful.

      Comment:

      Without a defined enumerated list it will be quite costly and will cause additional time to solution for the VHA to have a plug-and-play solution.

      Summary:

      Without a defined enumerated list it will be quite costly and will cause additional time to solution for the VHA to have a plug-and-play solution.

      Attachments

        Activity

          People

            Unassigned Unassigned
            kenlord Ken Lord
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: