Isn't data always going to be shared back to the payer to get the prior auth? - DTR #31

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • US Da Vinci DTR (FHIR)
    • STU3
    • Financial Mgmt
    • (profiles) [deprecated]
    • 4.4.9
    • Hide

      Will clarify - expand the reference wording to clarify use cases where collected info is not shared with the rule source.

      Note: PA is not the only use for DTR, it is also used for example, to augment documentation of medical * *necessity *. *

      Show
      Will clarify - expand the reference wording to clarify use cases where collected info is not shared with the rule source. Note: PA is not the only use for DTR, it is also used for example, to augment documentation of medical * *necessity *. *
    • Larry Decelles / Isaac Vetter: 14-0-6
    • Clarification
    • Non-substantive

      Existing Wording: When meeting the DTR / SMART on FHIR application requirements using a distinct app (i.e. not within the Electronic Health Record (EHR)), the app SHALL have a distinct client id for when it's being invoked purely as a mechanism to supplement EHR data vs. when it's being invoked to potentially share data back to the payer.

      Comment:

      This is unclear. Isn't data always going to be shared back to the payer to get the prior auth?

      Summary:

      Isn't data always going to be shared back to the payer to get the prior auth?

            Assignee:
            Unassigned
            Reporter:
            Kensaku Kawamoto
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: