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

stronger language needed

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Highest Highest
    • US Da Vinci CRD (FHIR)
    • 1.1.0-ballot [deprecated]
    • Financial Mgmt
    • STU
    • Supported Hooks
    • 4.2.1
    • Hide

      There's no such thing as 'pending' in this context.  The payer will either indicate "covered", "needs prior auth", "not covered", or one of the "unable to determine - need DTR" flavors.  We can't set any expectations about what percentage of orders will result in a determination without invocation of DTR because that's driven by the type of order, the type of information available in the order, and the type of information available elsewhere in the record and how computable it is.  It's also dependent on what the payer rules happen to be for a given payer's coverage.  It's in the payer's interest to maximize early determination because whatever can't be done in an automated fashion results in phone calls, human review and other factors that cost money.  It also provides a poorer patient experience.

      However, we will add the following language:

      "Where a payer responds with a "coverage information" code of 'clinical' or 'admin' and the payer supports DTR, they SHOULD support gathering the additional information via DTR.  This expectation is intended to change to SHALL in a future release."

      Show
      There's no such thing as 'pending' in this context.  The payer will either indicate "covered", "needs prior auth", "not covered", or one of the "unable to determine - need DTR" flavors.  We can't set any expectations about what percentage of orders will result in a determination without invocation of DTR because that's driven by the type of order, the type of information available in the order, and the type of information available elsewhere in the record and how computable it is.  It's also dependent on what the payer rules happen to be for a given payer's coverage.  It's in the payer's interest to maximize early determination because whatever can't be done in an automated fashion results in phone calls, human review and other factors that cost money.  It also provides a poorer patient experience. However, we will add the following language: "Where a payer responds with a "coverage information" code of 'clinical' or 'admin' and the payer supports DTR, they SHOULD support gathering the additional information via DTR.  This expectation is intended to change to SHALL in a future release."
    • Bob Dieterle / Andy Stechischin : 8-0-1
    • Clarification
    • Non-substantive
    • Yes

    Description

      Regarding statement that "Servers SHALL provide their card responses within 5 seconds, 95% of the time." What is to keep a payer from just pending in order to meet the expectation? Suggest adding stronger language that response MUST be as complete as possible in order to be conformant with the IG. For example, could edit the next sentence to say SHALL instead of SHOULD provide the best information...

      Attachments

        Activity

          People

            Unassigned Unassigned
            celine_lefebvre Celine Lefebvre
            Celine Lefebvre
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: