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

Deferring and relaunching DTR App

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci DTR (FHIR)
    • current
    • Clinical Decision Support
    • DTR Questionnaire Response
    • Formal Specification
    • Hide

      We will make clear in the CRD specification that:

      1. When EHRs pass resources to a CRD as part of context, the resources SHALL have an id and that id SHALL be useable as a target for references in resources manipulated by CDS Hook actions and/or by SMART apps launched by CRD.  This does not mean that the ids passed to CRD must persist, but rather that the EHR must handle adjustments to any references made to them (or provide necessary redirects) ensuring that any references made to the in-memory resource will remain valid.  This also means that EHRs will need to support the creation or updating of resources that include references to resources that might, at the time, only exist in memory and not yet be available as persistent entities.

      In DTR:

      1. We will define an extension that allows a QuestionnaireResponse to link to the order/appointment/etc. it pertains to.  EHRs will need to allow their users to navigate to and select work-in-progress Questionnaires associated with a given order.
      2. We will also define an extension that allows a QuestionnaireResponse to be associated with a Coverage the QuestionnaireResponse pertains to.  (Possible we might just have a single 'context' extension that allows pointing to 0..* resources and leverage that for both the order and Coverage.)
      3. We will define two new launch contexts for SMART on FHIR that must be supported by DTR - current order and current QuestionnaireResponse.
        1. If no QuestionnaireResponse is passed, SMART app will query the EHR to try to find the QuestionnaireResponses linked to that order (by the extension)
        2. If there are multiple QuestionnaireResponses for an order, will need to investigate whether it's possible to pass multiple responses as a launch context.
      4. When an EHR launches a DTR smart app and receives the context of the QuestionnaireResponse and, from that, the order and the payer, it will then have enough information to hit a standard operation defined on the Payer that allows retrieval of the relevant DTR package - which will contain the Questionnaire, associated value sets and/or CQL libraries.
      5. For EHRs that can't support the above, we will store 'interim' data on the payer system (with rules that it can ONLY be used to support DTR) and will return the final result as a PDF in a DocumentReference that contains the original order, the questionnaire response and, if appropriate, the prior authorization information.  This won't be computably linked to the order, though it SHALL be tied to the same encounter that was associated with the order (if any)
        1. Stored data will be:
          DocumentReference.subject.reference=EHR Patient URL
          DocumentReference.subject.identifier=Payer member identifier
          DocumentReference.author=Provider organization reference
          DocumentReference.date=current date
          DocumentReference.meta.lastUpdated=last changed
        2. Payers will only allow DocumentReferences to accessible to the apps that created them.  This will be enforced through the registration and authentication process payers will use with apps.  (I.e. there must be a shared secret that allows an app to establish identity with the payer.)  If a provider switches apps, they will not be able to access work in progress created by the previous app.
        3. DTR app will pass the EHR's token on to the payer as the "access token" when attempting to write or search the DocumentReferences stored on the EHR
          1. Payer SHALL inspect the token and verify that
            1. it was signed by a known/trusted EHR (that's known to be associated with the provider organization present in the search or the POSTed DocumentReference)
            2. it grants access to the same Patient for which the search or POSTed DocumentReference refers
          2. Payer SHALL NOT use the access token to query data itself.  EHR can monitor IP addresses to theoretically disambiguate if there are questions.

      We will will make clear that the DTR link should only be provided if there's information within the DTR Questionnaire that needs to be filled out by the current user.

       

      Show
      We will make clear in the CRD specification that: When EHRs pass resources to a CRD as part of context, the resources SHALL have an id and that id SHALL be useable as a target for references in resources manipulated by CDS Hook actions and/or by SMART apps launched by CRD.  This does not mean that the ids passed to CRD must persist, but rather that the EHR must handle adjustments to any references made to them (or provide necessary redirects) ensuring that any references made to the in-memory resource will remain valid.  This also means that EHRs will need to support the creation or updating of resources that include references to resources that might, at the time, only exist in memory and not yet be available as persistent entities. In DTR: We will define an extension that allows a QuestionnaireResponse to link to the order/appointment/etc. it pertains to.  EHRs will need to allow their users to navigate to and select work-in-progress Questionnaires associated with a given order. We will also define an extension that allows a QuestionnaireResponse to be associated with a Coverage the QuestionnaireResponse pertains to.  (Possible we might just have a single 'context' extension that allows pointing to 0..* resources and leverage that for both the order and Coverage.) We will define two new launch contexts for SMART on FHIR that must be supported by DTR - current order and current QuestionnaireResponse. If no QuestionnaireResponse is passed, SMART app will query the EHR to try to find the QuestionnaireResponses linked to that order (by the extension) If there are multiple QuestionnaireResponses for an order, will need to investigate whether it's possible to pass multiple responses as a launch context. When an EHR launches a DTR smart app and receives the context of the QuestionnaireResponse and, from that, the order and the payer, it will then have enough information to hit a standard operation defined on the Payer that allows retrieval of the relevant DTR package - which will contain the Questionnaire, associated value sets and/or CQL libraries. For EHRs that can't support the above , we will store 'interim' data on the payer system (with rules that it can ONLY be used to support DTR) and will return the final result as a PDF in a DocumentReference that contains the original order, the questionnaire response and, if appropriate, the prior authorization information.  This won't be computably linked to the order, though it SHALL be tied to the same encounter that was associated with the order (if any) Stored data will be: DocumentReference.subject.reference=EHR Patient URL DocumentReference.subject.identifier=Payer member identifier DocumentReference.author=Provider organization reference DocumentReference.date=current date DocumentReference.meta.lastUpdated=last changed Payers will only allow DocumentReferences to accessible to the apps that created them.  This will be enforced through the registration and authentication process payers will use with apps.  (I.e. there must be a shared secret that allows an app to establish identity with the payer.)  If a provider switches apps, they will not be able to access work in progress created by the previous app. DTR app will pass the EHR's token on to the payer as the "access token" when attempting to write or search the DocumentReferences stored on the EHR Payer SHALL inspect the token and verify that it was signed by a known/trusted EHR (that's known to be associated with the provider organization present in the search or the POSTed DocumentReference) it grants access to the same Patient for which the search or POSTed DocumentReference refers Payer SHALL NOT use the access token to query data itself.  EHR can monitor IP addresses to theoretically disambiguate if there are questions. We will will make clear that the DTR link should only be provided if there's information within the DTR Questionnaire that needs to be filled out by the current user.  
    • Bob Dieterle/Lloyd McKenzie: 14-5-5
    • Enhancement
    • Compatible, substantive

    Description

      This JIRA ticket is being created in response to the action item from the 2021-11-12 Burden Reduction call https://confluence.hl7.org/pages/viewpage.action?pageId=81004845

      • Varghese Mathew - Write up proposed solution into a JIRA Ticket for getting feedback. Proposed solution to the DTR re-launch to save and finish later when ids may change or not exist yet so we can get feedback from other EHRs (Rajesh Godavarthi  will get one more in the next wee.)  Include how the write the questionnaireresponse and the order in launch context and the fully formed questionnaire being filled in the same response.  (rough note to jog memory) - came up on 11/10 in context of JIRA ticket FHIR-34128 

      -----------------------------------------------------

      First, CRD will inform the Provider EHR in a semantically understandable fashion that prior authorization is/maybe required. (If it is an independent DTR launch without CRD, it could be EHR internal rules that make the determination that prior authorization is required).

      Once it is know that for one or more services, prior authorization is required, we introduce a new SMART on FHIR launch context which can include 

      1. (required) ServiceRequest(s)(or DeviceRequests etc.) that require prior authorization
      2. (optional) QuestionnaireResponse(s) from any previous DTR launch.

      The very first time, the EHR launches DTR without #2 - QuestionnaireResponse(s). The DTR App will do it's "usual" work of determining the coverage and payer, fetching Questionnaire and CQL, and will gather information from the end user. Now whether the end user completes all required data or only partially fills DTR, the App files the (complete or partial) QuestionnaireResponse using the same mechanism described in current DTR spec to file the finished DTR questionnaire. This QuestionnaireResponse(s) is filed to the EHR FHIR server. The EHR already needs to have internal mechanisms to associate this QuestionnaireResponse(s) with the order(s) so that this can be included in the PAS request.

      It must also be clarified that in this first launch, the EHR will pass the FHIR ID of the draft order(s) in the DTR launch. The QuestionnaireResponse will then have a reference to these orders through this FHIR ID provided to the DTR App when it files the QuestionnaireResponse with the EHR. 

      Now, if the FHIR ID of the order(s) changes, then the EHR is able to update the QuestionnaireResponse to have the correct FHIR IDs, since it understands this linkage.

      Upon a subsequent launch, say to finish a previously partially filled out DTR (whether by the same user, or by a different user), the EHR will launch DTR with (1) the CURRENT FHIR ID(s) of the order(s), and (2) QuestionnaireResponse(s) it has previously saved associated with these orders. 

      (Optionally, we can also have the DTR App at this point do validation. If the FHIR IDs in the order reference do not match the order FHIR IDs in the launch, the DTR App can update the QuestionnaireResponse(s) with the correct order IDs. But I personally think, doing this on the EHR would be safer?)

      Now, in this subsequent DTR launch, the App still determines payer and coverage from the order by fetching the order. Once the app determines payer and coverage, it fetches the Questionnaire and CQL per its usual process. If these have changed significantly, it may need to drop any previous QuestionnaireResponse(s) and start afresh, but that is the super uncommon case. Then it uses the information in the QuestionnaireResponse(s) to update the UI to whatever the user previously left off at. Now the user can continue from where they left off and fill additional information. 

      This repeated launch and filing back to EHR can be done how-many-ever times as necessary. After some iterations, all information is filled, and the App can file a completed QuestionnaireResponse completing the DTR interation. 

      At this point, the EHR will then begin the PAS workflow. 

       

      This also means

      • There is no need for any Task or additional resources for this workflow.
      • There is no need for additional secure connections between the App and the Payer allowing the app to file any data to payer, nor any security concerns arising out of so doing. 
      • There is no additional capability such as DocumentReference required either on the payer's or the EHR's side.
      • In fact, even CRD does not need to return a DTR App link - all that CRD needs to return is the discrete information about whether prior authorization is required or not for each service.
      • This model is simple and doesn't involve much additional work on either Payer or EHR for a mult-launch DTR as against a single launch DTR.

       

      Let me know if I captured everything correctly per our discussion, or if there are any additional concerns.

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: