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

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

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium 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

    Description

      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?

      Attachments

        Activity

          People

            Unassigned Unassigned
            kensaku_kawamoto Kensaku Kawamoto
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: