"alert fatigue" => "app fatigue" - DTR #56

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • US Da Vinci DTR (FHIR)
    • STU3
    • Clinical Decision Support
    • (profiles) [deprecated]
    • Process Flow
    • Hide

      The issue here is that CRD is invoked to determine if prior authorization is needed and, if so, what data needs to be sent. The data can't actually be sent to the payer and stored at this point in the workflow because the order hasn't been completed and no decision has been made to seek prior authorization. All we can do is provide the templates to the EHR for subsequent use - and the only way to do that with CRD is with a card. If you see alternative possible workflows, please suggest.

      Where there's no need for information to flow to a payer and the only requirement is that documentation exists in the EHR, agree there's no need to invoke DTR. We can explicitly add language noting that DTR should only be returned if the relevant information can't be found in the EHR and/or there's a need for data to flow to the payer.

      Will work out with ballot commenter a mutually acceptable solution

      Need to explore the option for a fully payer side PA where the only interaction with the provider is the initiation of the CDS request and a response with the PA number or a pended request that is completed via the PAS method for notification on PENDED PA requests.

      Show
      The issue here is that CRD is invoked to determine if prior authorization is needed and, if so, what data needs to be sent. The data can't actually be sent to the payer and stored at this point in the workflow because the order hasn't been completed and no decision has been made to seek prior authorization. All we can do is provide the templates to the EHR for subsequent use - and the only way to do that with CRD is with a card. If you see alternative possible workflows, please suggest. Where there's no need for information to flow to a payer and the only requirement is that documentation exists in the EHR, agree there's no need to invoke DTR. We can explicitly add language noting that DTR should only be returned if the relevant information can't be found in the EHR and/or there's a need for data to flow to the payer. Will work out with ballot commenter a mutually acceptable solution Need to explore the option for a fully payer side PA where the only interaction with the provider is the initiation of the CDS request and a response with the PA number or a pended request that is completed via the PAS method for notification on PENDED PA requests.
    • Bob Dieterle / Rachael Foerster: 8-0-0
    • Clarification
    • Non-substantive

      Existing Wording: This IG leverages CQL to allow payers to inspect a patient's record for the necessary information related to the required documentation for a proposed item.

      ...

      One of the core purposes of this specification is to automate the processing of payer rules in a manner that reduces provider burden.

      …

      The DTR application will then use the statement identifier to retrieve a value from CQL execution. The resulting value is used to satisfy documentation requirements. If the value is null, the user will be prompted to supply a value.

      Comment:

      An app should only be returned to the user if the CDS Service already determined that manual user action is required. Receiving a CDS Hooks card is disruptive to a user's workflow. Launching an app from a card is even more disruptive. The CDS service MUST evaluate the DT rules in deciding if a card should be returned. A card should only be displayed if the CDS service was not able to automatically satisfy the required rules. The app MUST not be returned tot he user if the documentation exists within the EHR and is accessible.

      Summary:

      "alert fatigue" => "app fatigue"

            Assignee:
            Unassigned
            Reporter:
            Michael Clifton
            Michael Clifton
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: