Detailed Mash up of CDex and DTR to leverage DTR which is being or will be implemented by EHRs. ![](https://hackmd.io/_uploads/Sy42Qj-8j.png) ## What does a CDex Attachments Questionnaire Look Like ### Pre-Populating Questionnaires The secret sauce in reducing provider burden in using CDex Attachments and DTR is that the Questionnaires are *pre-populated* (The questionnaire can identify the specific data element that should be used to fill out the form) before the provider staff reviews it. In order for this to work the data needs to be availabe as FHIR resources and specifically US Core Profiles from [certified EHRs](https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program). This normalizes the data structures across providers. ### How Does the CDex Questionnaire Identify the Specific Data Element? Populating a QuestionnaireResponse is a complex task. The system must be able to query resources, use CQL to populate and potentially calculate relevant data elements, manage conditionality rules around enableWhen as part of the population process, etc. This CQL may query for patient observations, conditions, or other discrete information within the EHR to use as part of the population process or logic. Another alternative is to use the [Adaptive Form mechanism](https://en.wikipedia.org/wiki/Computerized_adaptive_testing). It hides the design of the questionnaire entirely and, in principle, allows the service to determine the next question to automatically fill in (or perhaps even suppress asking questions) based on data the service can access about the patient. :::info Adaptive Questionnaires can essentially mimic current Payer Portal functionality ::: ### Designing Questionnaires to Support Pre-Population For CDex the [expression-based](http://hl7.org/fhir/uv/sdc/expressions.html) pre-population approach is used. It supports retrieving data from any queryable FHIR resources available on the source system. Those queries can be based on the context in which the QuestionnaireResponse is being generated and/or on the results of other queries. Furthermore, it permits CQL operations to be done on the resulting data such as calculations, conditional determinations, etc. :::warning Technical Stuff Ahead! ::: #### Expression Extensions Expressions are introduced into Questionnaires using extensions. Specifically we use the following extensions: 1. [library](https://hl7.org/fhir/extensions/StructureDefinition-cqf-library.html): A reference to a Library containing the formal CQF logic used by the artifact. 2. [CQF Expression](https://hl7.org/fhir/extensions/StructureDefinition-cqf-expression.html): An expression that, when evaluated, provides the value for the `Questionnaire.item` element (i.e., the question) on which it appears. <!-- 3. [launchContext](http://hl7.org/fhir/uv/sdc/expressions.html#launchContext) 4. [itemPopulationContext](http://hl7.org/fhir/uv/sdc/expressions.html#launchContext) 5. [variable](http://hl7.org/fhir/R4/extension-variable.html) 6. [initialExpression](http://hl7.org/fhir/uv/sdc/StructureDefinition-sdc-questionnaire-initialExpression.html) --> CDex + DTR Rules (Adapted from the DTR IG): 1. CQL SHALL have a context of `Patient` ( `Task` is not a requirement although The DTR App has access to it and it does contain extra Payer provided context) 2. The expressions in the [CQF Expression](https://hl7.org/fhir/extensions/StructureDefinition-cqf-expression.html) extensions reference a named expression defined in a Library referenced by the containing resource. 4. For each Questionnaire.item with a null value for the cqf-expression, user input will be required to obtain the desired information 5. Questionnaires and ValueSets SHALL be version specific to address the possibility of breaking changes between differing versions. TODO :construction_worker: 6. All value sets will be expanded as of the current date and using expansion parameters (such as SNOMED release) as deemed appropriate by he server :::spoiler **Click to See Example Questionnaire with Expression Extensions** #### Example Questionnaire with Expression Extensions {%gist Healthedata1/e054bdbcc9d31ad170d1d9d50f6b0dbe %} ::: #### Expression Extensions are Defined in the [Library](https://hl7.org/fhir/R4/library.html) Resource - The FHIR Libraries **SHALL** include the `content.data` element containing a base-64 encoded string of the CQL content - The app SHOULD retrieve the FHIR resources specified in the dataRequirement section of a Library, it can then pass these resources to the Clinical Quality Language (CQL) engine. Using dataRequirement allows for a more declarative means of understanding the resource data needed from the EHR :::info :thinking_face: Although it may seem redundant to have dataRequirement section of a Library since technically the CQL can work without it? The data requirements allows the DTR app to collect the data that the CQL expressions will need to evaluate *prior* to making the call and sending it with the request so that the CQL engine doesn't have to call back to the server. It's the same as "prefetch" in CDS Hooks. The DTR app will still have to make those calls, but it could potentially issue the queries all at once (i.e. in a bundle), rather than individually. See the [Providing Context to the CQL Execution Engine](#Providing-Context-to-the-CQL-Execution-Engine) Section below ::: :::spoiler **Click to See Example Library Resource** #### Example Library Resource {%gist Healthedata1/bf69950a52febf641d8fc13abdc73268 %} ::: ##### ValueSets defined for This Example For Question 1: This example value set that includes bespoke codes for reasons for a O2 therapy device request :::spoiler **Click to See Question 1 ValueSet** {%gist Healthedata1/7581d6c2a5f0d0de7a7b5499cf35214e %} ::: <br /> For Question 2: This example value set that includes bespoke codes for reasons for a O2 therapy device request :::spoiler **Click to See Question 2 ValueSet** {%gist Healthedata1/47a6d986ca7aea4bae00a97fdb743cfd %} ::: #### The [CQL]() expression language :::info There are "standard" CQL libraries: - FHIRHelpers - FHIRCommon - USCoreElements - USCoreCommon that can be used to modularize the CQL expression This example is has been validated using the [VSCode CQL Unit Testing Plugin](https://marketplace.visualstudio.com/items?itemName=cqframework.cql) ::: :::spoiler **Click to See CQL Expression** {%gist Healthedata1/646b2eba5e4b87ec02a4c95fb1aef59b %} ::: ### How DTR Prepopulates the QuestionniareResponse #### CDex PreRequisite Steps ![](https://hackmd.io/_uploads/rJWJ3-Y_3.png) #### CDex Launches DTR: Passing the Context of Patient and Task from CDex to DTR The Task.code trigger's CDex to Launch DTR. Assuming that the DTR App is a SMART on FHIR App*, After [launching the DTR App from CDex](http://hl7.org/fhir/us/davinci-cdex/requesting-attachments-questionnaire.html#dtr-smart-app-launch), the SMART launch context is passed in the Access Token provided by the EHR/Authorization Server. This SMART launch context *includes the local reference to the Task*. TASK provides tracking ID, Claim ID, provider ID, patient ID, date of service, etc mapped from the 278 response (The encounter is not specifically referenced.) In the next step the DTR App fetches the Task and uses the questionnaire URL which it uses to get a "Questionnaire Package" from the Payer using an operation defined in DTR. :::spoiler **Click to See DTR Launch Sequence** ![](https://hackmd.io/_uploads/BJI3ibFdh.png) ::: :::info \* if the DTR functionality is embedded directly into the EHR, then the interaction is implementation specific. ::: #### Fetching and inspecting the Task After launch the DTR App fetches the Task to get the necessary input data including the the Questionnaire URL. ```sequence Note over Provider EHR/Authorization Server: SMART App Launch Provider EHR/Authorization Server->DTR App: Access Token with\n local reference to Task DTR App->Provider EHR/Authorization Server: GET Task Provider EHR/Authorization Server-->DTR App: Note over DTR App: DTR App inspects Task\nfor Questionnaire URL ``` :::spoiler **Click to See CDex Task Example** The `Task.input:questionnaire` element contains the canonical URL for the Questionniare. {%gist Healthedata1/059027eae1c63cf3c32004aa3564de28 %} ::: #### Fetching the “Questionnaire Package” The “Questionnaire Package” is a Payer supplied Bundle of resource consisting of all the stuff shown above - a single Questionnaire resource Library(s) and any ValueSet and CodeSystems needed to allow DTR App to prepopulate and fully render the Questionnaire. It may also contained Partially Pre-populated QuestionnaireResponse that the provider needs to review and complete. See the Example $questionnaire-package Operation below for an example “Questionnaire Package” Bundle ##### `$questionnaire-package` Operation The Questionnaire URL contained in the Task is required to fetch the "Questionnaire Package" using the [DTRQuestionnaireOperation](http://build.fhir.org/ig/HL7/davinci-dtr/OperationDefinition-questionnaire-package.html)`$questionnaire-package`. The DTR App invokes this operation on the Payer's Server (Rules Repository) and it returns 1 or more collection Bundles. #### Sequence Diagram From DTR Launch to Fetching to Questionnaire Package ```sequence DTR App->Payer: $questionnaire-package Payer-->DTR App: returns “Questionnaire Package” ``` :::spoiler **Click to show the $questionnaire-package Operation interaction details** #### Provider Invokes Operation on Payer's Server Note: DTR OperationDefinition requires a Coverage resource, but this is not needed fot the CDEX use case ... submit tracker to DTR :thinking_face: ~~~ GET [base]/Questionnaire/$questionnaire-package?questionnaire=http://example.org/cdex-questionnaire-example1 ~~~ ##### Response from Payer's FHIR Server {%gist Healthedata1/957f6719ee56b78bd047513ba77621cf %} ::: ### Executing the CQL DTR interacts with the Provider's FHIR Server to prepopulate the Questionnaire. Either the CQL Server-side functionality is enabled and can directly return the data based on the CQL evalution (see the [CQL Ruler](https://github.com/dbcg/cqf-ruler) for an example). Or the CQL is executed on the DTR Client which needs to query the Server for the resources it needs and then extract the data(see the [cql-exec-fhir](https://github.com/cqframework/cql-exec-fhir)). #### Providing Context to the CQL Execution Engine. To execute the CQL, the DTR Client needs to fetch Resources from the Provider FHIR Server. (From [DTR](http://build.fhir.org/ig/HL7/davinci-dtr/specification.html#execution-of-cql)) >The app **SHOULD** retrieve the FHIR resources specified in the dataRequirement section of a Library, it can then pass these resources to the Clinical Quality Language (CQL) engine. Using dataRequirement allows for a more declarative means of understanding the resource data needed from the EHR. Therefore, the DTR App inspects the Library Resources and does a FHIR RESTful search for the necessary resources from the Provider's FHIR server. :::info this could be a series of queries or a batch transaction ```sequence note over DTR App: Inspect Library.dataRequirements DTR App->Provider: GET [base/[Resource]?[parameters] Provider-->DTR App: returns Resource ``` ##### Questions??? :thinking_face: What is the time period of interest (claim/encounter date)? and how is it expressed in [`DataRequirement.dateFilter`](https://hl7.org/fhir/R4/library-definitions.html#Library.dataRequirement) to limit data retrieved. (hard code it each time, relative date to the Questionnaire? Since it is a value *before* evaluation can't use an expression.) :thinking_face: Should there be an operation defined that does this interaction... ::: :::spoiler **Click to See Batch Search and Bundle of Resource returned** See the DataRequirement section of a Library Above **Request:** `POST [base]` payload: ~~~yaml resourceType: Bundle id: batch-request-cdex-example1 type: batch entry: - request: method: GET url: /Condtion?patient=example&category=problem-list-item&status=active&code=http://example.org/cdex-valueset-o2-conditions| - request: method: GET url: /DeviceRequest?patient=example&status=active&reasonCode=http://example.org/cdex-valueset-o2-reasoncodes| ~~~ **Response:** `200 OK` payload: {%gist Healthedata1/b10294b4d7e2ec9bc853b5b97fefa05a %} ::: #### Executing the CQL to get Defined Parameters After collection the needed resource the DTR App evaluates the CQL using a cql evaluation tool to yield values for the named parameters in the Questionnaire Expression Extensions. ```sequence DTR App->DTR App: Evaluate CQL ``` :::spoiler **Click to See Execution of CQL** ~~~ Executing CQL... CQL path: /Users/ehaas/Documents/CQL/cqf-us/input/cql Data path: /Users/ehaas/Documents/CQL/cqf-us/input/tests/Example1 Terminology path: /Users/ehaas/Documents/CQL/cqf-us/input/vocabulary/valueset Task=Task(id=example-1-task) EncounterDate=2022-06-17T16:16:06 Patient=Patient(id=example) RelevantPatientDiagnosis=[Chronic Obstructive Lung Disease] OrderReason=[1] Evaluation logs: 18:00:39.793 [pool-2-thread-1] INFO ca.uhn.fhir.context.FhirContext - Creating new FHIR context for FHIR version [R4] 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet urn:oid:2.16.840.1.113883.3.464.1003.102.12.1012 is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/detailed-ethnicity is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-appropriateness-score is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-condition-stage is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-servicerequest-reason-rejected is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-narrative-status is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-provenance-participant-type is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-observation-smoking-status-status is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/detailed-race is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-procedure-code is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-documentreference-category is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-encounter-canceled-reason is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-medication-codes is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-bodystructure-precoordinated is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.158 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-allergy-substance is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-observation-verification is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-observation-smokingstatus is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-condition-certainty is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/birthsex is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-vaccines-cvx is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-encounter-type is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-negation-reason is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-priority is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-procedure-icd10pcs is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-allergyintolerance-reason-refuted is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-observation-body-position is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-diagnosticreport-report-and-note-codes is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-medication-dose-type is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-ndc-vaccine-codes is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-communication-reason-not-performed is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-careteam-provider-roles is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/omb-ethnicity-category is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-observation-value-codes is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-flag-category is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-encounter-condition-role is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/simple-language is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-condition-code is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-clinical-note-type is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-procedure-type is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/omb-race-category is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-provider-role is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-documentreference-type is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-condition-criticality is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-provider-specialty is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-diagnosticreport-category is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-goal-reason-rejected is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-diagnosticreport-lab-codes is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-condition-category is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-observation-delta is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/qicore/ValueSet/qicore-patient-disability is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-usps-state is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet http://hl7.org/fhir/us/core/ValueSet/us-core-smoking-status-observation-codes is not expanded. Falling back to compose definition. This will potentially produce incorrect results. 18:00:40.159 [pool-2-thread-1] WARN o.o.c.c.e.e.terminology.BundleTerminologyProvider - ValueSet urn:oid:2.16.840.1.113883.3.464.1003.102.12.1011 is not expanded. Falling back to compose definition. This will potentially produce incorrect results. elapsed: 0.375 seconds ~~~ ::: ### Recording Responses The named parameters values are used to prepopulate the items in the QuestionnaireResponse. (from [DTR](http://build.fhir.org/ig/HL7/davinci-dtr/specification.html#recording-responses)) > The DTR process SHALL create a QuestionnaireResponse resource based on all of the information collected. > - If the value was supplied by the user, the author extension property will be set. > - if the user did not supply a value, but provided an attestation that the information exists in the patient’s record, it would be represented by the http://hl7.org/fhir/StructureDefinition/questionnaireresponse-signature extension ```sequence DTR App->DTR App: Prepopulate Questionnaire\n--- DTR App->Practitioner: Manual Review and\n Completion of QuestionnaireResponse Practitioner-->DTR App: ``` :::spoiler **Click to show Completed Questionnaire Response** {%gist Healthedata1/770377b7f6ffe3d0eaa217bf6da7d284 %} ::: ### Updating the Task and POSTing the Completed QuestionnaireResponse The DTR App SHALL create (POST) the QuestionnaireResponse to the Provider's FHIR Server. When the QuestionnaireResponse is complete, the DTR App updates the Tasks's `status` to "completed and the Task's output to reference the completed QuestionnaireResponse. ```sequence DTR App->Provider: POST QuestionnaireResponse Provider-->DTR App: note over DTR App: When QuestionnaireResponse is complete DTR App->Provider: Update QuestionnaireResponse.status to "completed" Provider-->DTR App: DTR App->Provider: Update Task to "completed" and reference\nthe QuestionnaireResponse in Task.output Provider-->DTR App: ``` :::spoiler **Click to Show Interaction Details for Creating and Updating QuestionnaireResponse and Task** #### POSTing the QuestionnaireResponse on the Provider's Server ~~~ POST [base]/QuestionnaireResponse ~~~ ##### Payload (Completed Questionnaire) {%gist Healthedata1/770377b7f6ffe3d0eaa217bf6da7d284 %} *Response Headers* ~~~ HTTP/1.1 200 OK Server: CDEX Example Server Location: [base]/QuestionnaireResponse/cdex-questionnaireresponse-example1/_history/1 ...(other headers) ~~~ #### Updating the Task on the Provider's Server when the QuestionnaireResponse is Completed ~~~ PUT [base]/Task/cdex-attachments-questionnaire-task-example1 ~~~ ##### Payload (Updated Task) {%gist Healthedata1/b5110d32de8ce5d521679fbc2b8998ca %} *Response Headers* ~~~ HTTP/1.1 201 OK Server: CDEX Example Server Location: [base]/Task/cdex-attachments-questionnaire-task-example1/_history/ ...(other headers) ~~~ ::: ### Submitting the Completed QuestionnaireResponse to the Payer. When the Task is updated to "completed", the CDex App will invoke the `#submit-attachment` operation to the Payer's endpoint. The operation payload is a Parameters resource that contains the claim/prior-authorization metadata and the completed QuestionnaireResponse listed in the Task's output ```sequence note over CDEX: Task status is updated to "completed" CDEX->CDEX: Assemble Parameters resource for\n the operation payload\n--- CDEX->Payer: POST $submit-attachment with\n completed QuestionnaireResponse in payload Payer-->CDEX: ``` :::spoiler **Click to show the `$submit-attachment` Operation interaction details** #### Provider Invokes Operation on Payer's Server ~~~ POST [base]/$submit-attachment ~~~ ##### Payload {%gist Healthedata1/10c5270d2b3ed11c52df9946233c65f5 %} *Response Headers* ~~~ HTTP/1.1 200 OK ...(other headers) ~~~ ::: ## Burden Reduction and CDex *If the result of the Prior Auth is "pended" because additional data is required to complete it*, CDex can be used to supply the missing data. The following Sequence Diagram assumes a prior-auth has been submitted by a Provider and reviewed by the Payer who determines additional information is needed. It show the interactions between Payer Provider and the CDex and DTR apps in the Burden Reduction (Prior-Auth) workflow when additional information is needed. - The CDex And DTR boxes represent a separate SMARTon FHIR Application or intrinsic functionality in the EHR - The role of Intermediary is to translate the x12 278 response to a PAS Bundle - The X12 278 "pended" Response will be returned with either: 1. One or more "LOINC attachments code(s)" - requests a Document be returned **this one uses CDEX only (does not use DTR)** as indicated in the top half of the sequence diagram below. or 2. A single specific LOINC code which requests a Questionnaire with individual data elements be completed **this one uses CDEX and DTR)** as indicated in the bottom half of the sequence diagram below. - The tracking ID is associated with a each 278 response. There may be many responses to a single request and the Payer is responsible for keeping track of tracking IDs. ![](https://hackmd.io/_uploads/S1m8ga9S3.png) #### Issues 1. CDex Documentation: >Request Attachments Data Using a FHIR Questionnaire ...For CDex attachment requests transactions, the Payer SHALL use the CDex Task Attachment Request Profile to solicit information from a Provider... - In CDex the Provider is expecting a Task from the Payer for this transaction. The ability to respond to non-FHIR request applies only to LOINC Attachments codes. - So we would need to update CDex to say that a Payer can request Attachments Data Using a Questionnaire as a "non-FHIR" Payer request using a new LOINC Attachments codes? The Provider would then need to create the Task from a "non-FHIR" Payer request to exchange with DTR. 2. The $questionnaire-package endpoint is based on the Questionnaire URL (see above) 3. These interactions are between the DTR App and the EHR/FHIR Server not CDex App. 4. Cdex $submit-attachment payload is a Parameters Resource not a Bundle as indicated in the diagram. There can be multiple Attachment parameters each containing a single resource like DocumentReference or QuestionnaireResponse or a Bundle. 5. Can the Intermediary submit the Task directly (or indirectly through EHR/CDex) to DTR? no its only function is to translate from X12 to FHIR. - The CDex Task Attachment Request Profile maps to the 278 Response - As proposed above, the Intermediary is transforming the "pended" 278 Response to a PAS response Bundle ([see below](#What-is-a-PAS-Response-Bundle)) that the EHR has to turn around and transform to a Task. This adds more responsibility to the EHR #### What is the expected system behavior and requirements before PAS kicks-off CDex? Updated PAS flow diagrams in CDex ```flow st=>start: Provider PA request results in "pended result" Payer needs more info sr1=>subroutine: Payer creates X12 278 response "pended result" with LOINCs detailing what is needed sr2=>subroutine: intermediary translates 278 to "PAS Bundle" sr2.5=>subroutine: Payer translates "PAS Bundle" to CDex Task Attachment Request Profile cond1=>condition: CDex Task Attachment Request using LOINC Attachment (Document) Codes? cond2=>condition: CDex Task Attachment Request to Complete Questionnaire sr3=>subroutine: CDex $submit-attachment with Document Payload sr5=>subroutine: CDEx launches DTR to Complete Questionnaire (Task with Questionnaire url exchanged as result of SMART launch) sr6=>subroutine: DTR fetches Questionnaire Package sr7=>subroutine: DTR Pre-populates QuestionnaireResponse sr8=>subroutine: DTR Presents QuestionnaireResponse to User for Completion sr9=>subroutine: DTR Update Task and Creates QuestionnaireResponse on Provider FHIR server sr10=>subroutine: CDex $submit-attachment with QuestionnaireResponse Payload st->sr1->sr2->sr2.5->cond1 cond1(yes)->sr3 cond1(no)->cond2(yes)->sr5->sr6->sr7->sr8->sr9->sr10 ``` #### What is a PAS Response Bundle? An intermediary system converts the resulting 278 response into a response FHIR Bundle containing a ClaimResponse and associated resources source: http://build.fhir.org/ig/HL7/davinci-pas/specification.html ![](https://hackmd.io/_uploads/Skxkjg0Sn.png) #### :exclamation: Not Documented in CDex is that the Provider not the Payer creates and POSTs Task to the CDex App ### Using Adaptive Questionnaire see [Launching DTR for an Adaptive Forms](/N_72kRUfQRO9eU8PRjwB_A)