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

Guidance on this page needs to be rewritten

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci DTR (FHIR)
    • 1.0.0 [deprecated]
    • Clinical Decision Support
    • How DTR passes information to PAS, PAO or other exchanges [deprecated]
    • Hide

      Most of this is already covered by FHIR-41168.  However, there's still a need to talk about how an adaptive form can talk about prior auth requirements (e.g. 'satisfied').

      We will add the following to the section on adaptive forms in DTR:

      "In some cases, upon receiving enough answers from an adaptive form, a payer will be in a position to make assertions about coverage, prior authorization, and/or 'additional documentation needed' similar to what is provided by the CRD process.  This information needs to be made available to the DTR client in a computable fashion.  To do so, the adaptive form service will place the "coverage-information" extension on the root of the QuestionnaireResponse, alongside the 'pertinent-orders' extension.  When the QuestionnaireResponse is stored in the DTR client, client *SHALL* propagate the coverage-information extension into each of the pertinent-orders.

      NOTE: It will be unusual for a coverage-information extension created by an adaptive form to come back saying 'additional documentation required', however there are theoretical use-cases for this to be useful and this specification does not prohibit such behavior.  If this occurs, it may result in a subsequent launch of DTR, or could result in the DTR client prompting the user as to whether they want to move on to filling out the new form(s)."

      In CRD, we will update the context of the coverage-information extension to include QuestionnaireResponse.  We will also change DTR to have a dependency on CRD.  (This will likely mean migrating some codes needed for 41168 into CRD, where they're also used.)

      Show
      Most of this is already covered by FHIR-41168 .  However, there's still a need to talk about how an adaptive form can talk about prior auth requirements (e.g. 'satisfied'). We will add the following to the section on adaptive forms in DTR: "In some cases, upon receiving enough answers from an adaptive form, a payer will be in a position to make assertions about coverage, prior authorization, and/or 'additional documentation needed' similar to what is provided by the CRD process.  This information needs to be made available to the DTR client in a computable fashion.  To do so, the adaptive form service will place the "coverage-information" extension on the root of the QuestionnaireResponse, alongside the 'pertinent-orders' extension.  When the QuestionnaireResponse is stored in the DTR client, client * SHALL * propagate the coverage-information extension into each of the pertinent-orders. NOTE: It will be unusual for a coverage-information extension created by an adaptive form to come back saying 'additional documentation required', however there are theoretical use-cases for this to be useful and this specification does not prohibit such behavior.  If this occurs, it may result in a subsequent launch of DTR, or could result in the DTR client prompting the user as to whether they want to move on to filling out the new form(s)." In CRD, we will update the context of the coverage-information extension to include QuestionnaireResponse.  We will also change DTR to have a dependency on CRD.  (This will likely mean migrating some codes needed for 41168 into CRD, where they're also used.)
    • Lloyd McKenzie/Juliet Rubini: 17-0-1
    • Enhancement
    • Compatible, substantive

    Description

      This tracker replaces the https://jira.hl7.org/browse/FHIR-36513 tracker item.

      "The PAS Bundle linkId should be used for attached bundles containing resources needed for PAS"

      This isn't sufficiently clear and we've also decided to move away from an approach with 'magic' linkIds entirely.  What we actually need to say is:

      "When completing a Questionnaire, the contents of that questionnaire may have an intended use within the EHR.  The EHR must be informed of what type of action(s) are intended for the information in the Questionnaire.  This is managed through the [dtr-purpose extension] found in the DTR QuestionnaireResponse profile.  This extension is in turn propagated from the equivalent extension found on the Questionnaire instance the QR is responding to.

      This extension allows a QuestionnaireResponse to be associated with zero or more potential reasons:

      • include with prior authorization submission
      • include with claim submission
      • include with order transmission
      • retain for medical necessity documentation

      If a QuestionnaireResponse is tagged with any of the 'include with' reasons, that means that the EHR SHOULD include a QuestionnaireResponse Bundle for this response when transmitting the corresponding object.  A QuestionnaireResponse Bundle adheres to the [DTR-QR-Bundle profile] and includes the QuestionnaireResponse (as first entry) as well as all resources pointed to by the QuestionnaireResponse via answerReference elements.

      Question: do we also include the subject, author, and/or informer?

      In addition, each QuestionnaireResponse will include an [extension] that identifies which orders or other resources that QuestionnaireResponse pertains to to allow the EHR to identify when the QuestionnaireResponse is relevant to a particular order transmission, prior authorization submission, etc.

      Unsolicited Coverage Determination

      In addition to the entire QuestionnaireResponse being used for a particular purpose, an adaptive QuestionnaireResponse might result in an unsolicited "coverage determination" based on the answers provided.  The EHR storing the QuestionnaireResponse will typically want to be able to extract this information for subsequent use within their authorization and billing process.  In this case, rather than simply attaching the QuestionnaireResponse, the EHR needs to understand how to find this information within the response.  This will be handled by having a single item (typically the last time) in the QuestionnaireResponse with a special linkId of "DTR_COV_DETERM".  The answerReference for this item SHALL point to a contained ClaimResponse resource that complies with the [CRD Prior Authorization] profile.  This will contain all of the discrete information needed to understand what is covered/authorized.  The EHR SHOULD transfer this information into their internal claim coverage representation as though the determination had been retrieved from the payer over traditional channels, associating it with the relevant order(s)."

      We then need to define the extensions listed above and reference them in the Questionnaire and/or QuestionnaireResponse profiles as necessary.

      The section on SMART Web messaging should be dropped.  There's no interest in it at this time from the EHR vendors and the adopted mechanism described here supersedes it.

      Attachments

        Activity

          People

            Unassigned Unassigned
            lloyd Lloyd McKenzie
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: