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

"How DTR Passes Information" page is no longer accurate

    XMLWordPrintableJSON

Details

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

      Will make the changes as described

      Show
      Will make the changes as described
    • Lloyd McKenzie/Greg White: 18-0-0
    • Correction
    • Non-compatible

    Description

      (This supersedes https://jira.hl7.org/browse/FHIR-36513)

      The contents of this page needs to be completely replaced with the following (though it may make sense to merge this page in with other content of the IG)

      Proposed new language:

      "The information gathered via DTR can be used for a variety of purposes:

      • For inclusion as a prior authorization attachment (either via [PAS] or [CDex] or via traditional attachment submission mechanisms
      • For inclusion as a claims attachment as part of an X12 submission
      • To accompany the order so the information is available to the performing system as per the [FHIR Orders Exchange IG]
      • To be retained by the EHR in the event of a subsequent audit
      • Additional purposes as yet undefined

      Once DTR has written a QuestionnaireResponse to the DTR Client and updated the QuestionnaireResponse.status element to 'complete', the DTR Client needs to understand what action(s) it should take with the collected information.  This is accomplished via two extensions:

      • The [pertinentOrders] extension provides a reference to the Request resource(s) and/or Encounter that the QuestionnaireResponse relates to.
      • The [intendedUse] extension indicates how the EHR is to use the information with respect to the associated orders/records

      In those cases where a QuestionnaireResponse is to be used to convey information either to the payer or to downstream service providers, the DTR Client SHALL 'wrap' the QuestionnaireResponse in a 'collection' Bundle complying with the [questionnaireResponseBundle] profile.  This Bundle will include the QuestionnaireResponse entry as its initial entry and will then also include any resources that are referenced by the QuestionnaireResponse as answerReference that are not already [contained] within the QuestionnaireResponse.  This ensures that all necessary information is delivered without a need for subsequent queries.

      NOTE: Only those resources directly referenced in the QuestionnaireResponse are included.  If further references from a referenced resource are desired, the designer of the Questionnaire must ensure that these are also included as answers (possibly as hidden answers automatically populated by CQL within the Questionnaire).

      While multiple purposes are possible, the expectation is that all information in the QuestionnaireResponse will be used for that purpose.  E.g. If a QuestionnaireResponse had a purpose of "prior authorization" and "order transmission", then the full QuestionnaireResponse bundle would be sent as a prior authorization attachment and as an attachment when the order is sent to the performer.

      If there is a desire to send different content to different recipients, then distinct QuestionnaireResponses must be used.

      It is up to the DTR Client to determine the process by which attachments to prior auth requests, claims or orders are assembled - this could be done automatically, or with human review."

      In addition, the DTR guide needs to define the following:

      Extension pertinentOrders "Pertinent Orders"

      • Context: QuestionnaireResponse
      • Cardinality: 1..*
      • Data Type: Reference(Appointment | CommunicationRequest | DeviceRequest | Encounter | MedicationRequest | NutritionOrder | ServiceRequest | VisionPrescription)
      • Description: Identifies the resources that drove the collection of the information in this QuestionnaireResponse and for which the information should subsequently be used.

      Extension intendedUse "Intended Use"

      • Context: QuestionnaireResponse
      • Cardinality: 0..*
      • Data Type: CodeableConcept
      • Binding: extensible to a value set containing following codes from DTR temporary code system:
        • PA "Include with prior authorization" - The information in this QuestionnaireResponse should be packaged into a Bundle and submitted as part of (or in association with) a prior authorization for the associated request resource(s).
        • CLAIM "Include with claim submission" - The information in this QuestionnaireResponse should be packaged into a Bundle and submitted as part of (or in association with) the insurance claim for the services ordered by the associated request resource(s)
        • ORDER "Include with order transmission" - The information in this QuestionnaireResponse should be packaged into a Bundle and submitted along with (or referenced as supporting information to) the associated request resource(s)
        • RETAIN "retain for medical necessity documentation" - The information in this QuestionnaireResponse should be retained within the DTR as supporting evidence of the medical necessity of the associated request resource(s)

       

      questionnaireResponseBundle profile

      • invariant requiring that first entry be a QuestionnaireResponse resource
      • invariant requiring that all items with an answer.valueReference have a URL that matches a fullUrl in the Bundle
      • force the bundle type to be 'collection'

       

      Will update the existing DTR QuestionnaireResponse profile needs to be updated to include references to the above extensions.

      Will include a diagram showing what all of the above process and data structure will look like.

      Finally, will add the following language to the 'notes' section of the DTR QuestionnaireResponse profile:

      "This profile allows questions to be answered with a type of Reference.  I.e. The answer to a question might be pointing to an existing resource (a Practitioner, a Condition, a DocumentReference, etc.)  In general, all such answers SHOULD be references to resources held within the launching EHR.  However, with mutual agreement with the EMR, a payer MAY provide Questionnaires that allow answers as references to an external FHIR repository - e.g. a centralized practitioner or organization registry.  The EMR would need to have access to the external entries in order to allow them to be incorporated into the [QuestionnaireResponse Bundle]."

       

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: