XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive
    • Icon: Medium Medium
    • US Da Vinci DTR (FHIR)
    • 1.1.0-ballot [deprecated]
    • Clinical Decision Support
    • Use Cases and Overview
    • Hide

      •    Acknowledge that the current CRD, DTR, PAS, and CDex supporting the ePA workflow only focuses on the interactions between the provider HIT in total and the payer HIT in total, not the necessary interactions among the respective HIT solutions that make up the provider and payer HIT environment that need to participate in the ePA workflow

      •    Acknowledge that ONC should support certification where certified software can use generic (or generically referenced) relied upon software to meet certain requirements and can clearly specify the capabilities they rely  on without needing to assert each permutation of relied upon software with which they support the ePA workflow, and that further guidance is needed for the interactions necessary within each of the provider and payer HIT configurations based on the functions/roles of those HIT solutions 

      •    Update the next version of the ePA guides (CRD, DTR, PAS, CDex), and/or through a separate guide (possibly, a companion guide) with the necessary interaction specification/guidance to enable certification of individual HIT modules participating in the ePA workflow. This applies to both provider and payer HIT configurations in accordance with the approach set out in the attached slides.  This will enable a certification program to both allow for HIT the requires the relied upon software approach using predictable,  standards-based capabilities to participate in an ePA workflow and for HIT that provides full support for ePA workflow through its certified HIT. 

      •    Update the current guides to clarify the current scope and need for additional effort in accordance to the approach outline in the scope.

      •    Request Da Vinci seek adequate financial support to accelerate the process.

      Show
      •    Acknowledge that the current CRD, DTR, PAS, and CDex supporting the ePA workflow only focuses on the interactions between the provider HIT in total and the payer HIT in total, not the necessary interactions among the respective HIT solutions that make up the provider and payer HIT environment that need to participate in the ePA workflow •    Acknowledge that ONC should support certification where certified software can use generic (or generically referenced) relied upon software to meet certain requirements and can clearly specify the capabilities they rely  on without needing to assert each permutation of relied upon software with which they support the ePA workflow, and that further guidance is needed for the interactions necessary within each of the provider and payer HIT configurations based on the functions/roles of those HIT solutions  •    Update the next version of the ePA guides (CRD, DTR, PAS, CDex), and/or through a separate guide (possibly, a companion guide) with the necessary interaction specification/guidance to enable certification of individual HIT modules participating in the ePA workflow. This applies to both provider and payer HIT configurations in accordance with the approach set out in the attached slides.  This will enable a certification program to both allow for HIT the requires the relied upon software approach using predictable,  standards-based capabilities to participate in an ePA workflow and for HIT that provides full support for ePA workflow through its certified HIT.  •    Update the current guides to clarify the current scope and need for additional effort in accordance to the approach outline in the scope. •    Request Da Vinci seek adequate financial support to accelerate the process.
    • Bob Dieterle / Ben Hamlin : 9-0-0
    • Clarification
    • Non-substantive

    Description

      Depending on the configuration and initiating system, an EHR is not necessarily the system that initiates the DTR step. That can be a Scheduling, Registration, or Practice Management system, or it also could be the SMART App. The IG should not be that prescriptive. While the ordering provider should be able to indicate whether to proceed with requesting a prior authorization, that may be done by another person as we build out prior authorization.  Additionally, the step to progress from CRD to DTR may also be done by the capability supporting CRD depending on how that is orchestrated when the timelag is too great to go back to the initiating user's app.

      Attachments

        Activity

          People

            rgeimer Rick Geimer
            hbuitendijk Hans Buitendijk
            Hans Buitendijk
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: