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

CRD IG doesn't have a semantically differentiable way to say "indeterminate"

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Medium Medium
    • US Da Vinci CRD (FHIR)
    • current
    • Financial Mgmt
    • Supported Hooks
    • Hide

      CRD has been revamped considerably.  The coverage-information now breaks out three elements (covered, pa-needed, and doc-needed) which can each say 'conditional', meaning that more information is needed.  Furthermore, there's an element called 'info-needed' that indicates whether the information needed is related to something that could be available in a later hook call (performer, location, or timeframe).  

      As well, the adaptive form Questionnaire mechanism does allow a payer to provide a determination that prior authorization requirements are satisfied - and regular forms can have enough logic to at least indicate whether prior authorization is necessary or not and communicate that.  There is now a defined mechanism for DTR to provide an equivalent of the coverage-information provided by CRD as part of a QuestionnaireResponse.

      Therefore, we believe that the concerns raised here have been sufficiently addressed by other trackers and no further action is needed for this issue.

      Show
      CRD has been revamped considerably.  The coverage-information now breaks out three elements (covered, pa-needed, and doc-needed) which can each say 'conditional', meaning that more information is needed.  Furthermore, there's an element called 'info-needed' that indicates whether the information needed is related to something that could be available in a later hook call (performer, location, or timeframe).   As well, the adaptive form Questionnaire mechanism does allow a payer to provide a determination that prior authorization requirements are satisfied - and regular forms can have enough logic to at least indicate whether prior authorization is necessary or not and communicate that.  There is now a defined mechanism for DTR to provide an equivalent of the coverage-information provided by CRD as part of a QuestionnaireResponse. Therefore, we believe that the concerns raised here have been sufficiently addressed by other trackers and no further action is needed for this issue.
    • Bob Dieterle / Chris Cioffi : 8-0-0

    Description

      In CDS Hooks, early on in the design of specifications, we had identified 3 classes of results

      1. There are alerts to show
      2. There are no alerts to show
      3. We need more information before we can say if there are alerts to show

      The App Link follow-up was particularly designed for the #3 use-case. 

      However, the CRD IG uses the App Link to show a DTR App. The DTR App can be an independent App and not necessarily a Payer DTR App. It's function is not to determine if prior authorization is required, but to collect supporting information for the prior authorization submission assuming prior authorization is required, and save it back to the EHR FHIR Server. 

      This means, CRD does not have a semantically distinguishable way to capture #3 case of "we don't have enough information to determine if prior authorization is necessary"

      Using a card saying prior authorization "MAYBE" necessary - go fill out the DTR App, wouldn't work because

      1. the DTR App is not submitting the captured information to the payer, and so the payer doesn't have an opportunity to look at the info and make a determination until PAS submission comes through
      2. the provider side still has to fill out the same info (such as where is the service being performed? Who is the performing provider?) on the EHR side. This constitutes duplicative documentation, and there is no guarantee that the provider side will use the same values as they used in the App thereby invalidating the determination.

      Realistically, what needs to happen is that the CRD Service needs to be able to say to the EHR in a semantically understandable / discretely captured fashion that we don't have enough information, maybe even these are the missing pieces, and call back when you have those captured.

      Unfortunately, CDS Hooks may not be the best vehicle for this either

       

      Attachments

        Activity

          People

            Unassigned Unassigned
            m_varghese Varghese Mathew
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: