In DTR it states ...

>The DTR app SHALL support loading and rendering the adaptive form developed by the payer following the SDC adaptive form workflow.

[Potential Advantages](http://build.fhir.org/ig/HL7/davinci-dtr/specification.html#general-adaptive-form-support)

Here is an overview of adaptive forms as defined in [SDC](http://build.fhir.org/ig/HL7/sdc/adaptive.html):


## Assumptions

1. The Payer hosts the Adaptive Questionnaire Server that can administer a questionnaire based on its algorithms.
- It has a unique Endpoint and may host 1 to many adaptive forms ( vs a unique endpoint for each adaptive form)
- Each adaptive form has a unique identifer = base Questionnaire the 'adaptive' QuestionnaireResponse completion was executed against.
- It is treated as a “Black Box” (*a system which can be viewed in terms of its inputs and outputs, without any knowledge of its internal workings*)

1. DTR is the "The Form Filler" and launches the adaptive form supplying the inputs to and retrieving outputs from the Adaptive Questionnaire Server.

## Steps

1. The DTR App initiates the Adaptive Questionnaire by posting the initial "empty" QuestionnaireResponse to Adaptive Questionnaire Service’s `$next-question` operation endpoint.
- DTR fetches the initial empty *QuestionnaireResponse* from the Payer in the "questionnaire bundle"
3. the Adaptive Questionnaire Service’s returns the first question to the Form Filler.
- This and all subsequent questions can either be prepopulated by DTR or be answered by an end-user.
6. The DTR App returns the QuestionnaireResponse with the completed question the Adaptive Questionnaire Service’s operation endpoint.
7. Based on the prior questions and answers, the Adaptive Questionnaire Service returns the next question to the DTR App.
8. Steps 3 and 4 are repeated until the Adaptive Questionnaire Service determines that the questionnaire is completed.

## Technical Constraints From SDC and DTR

1. [SDC Adaptive Questionnaire](http://hl7.org/fhir/uv/sdc/STU3/StructureDefinition-sdc-questionnaire-adapt.html):
- Mandatory
- [Questionnaire Adaptive Extension](http://hl7.org/fhir/uv/sdc/STU3/StructureDefinition-sdc-questionnaire-questionnaireAdaptive.html)
- Name for this questionnaire (human friendly)
- canonical URL for the Base Questionnaire this adaptive instance is derived from (:thinking_face: does this mean it must be a FHIR Questionnaire)
- Forbidden
- url

1. [DTR SDC Questionnaire for adaptive form](http://hl7.org/fhir/us/davinci-dtr/StructureDefinition/dtr-sdc-questionnaire-adapt)
- text element(Text summary of the resource, for human interpretation)

1. [SDC Adaptive QuestionnaireResponse](http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaireresponse-adapt)
- Mandatory
- contained (Questionnaire)
- Questionnaire url <- references the contained Questionnaire.id!
- date authored

:::spoiler Click to See Annotated Example Adaptive Form:

{%gist Healthedata1/1d9b6d4ce34a691ea8a41aa52e40dd7c %}

:::

## :thinking_face: **What is needed from payer to Launch an Adaptive Form from DTR App?**

:raised_hand:
1. The Payer-supplied Questionnaire package bundle would contain a "starter QuestionnaireResponse" along with the Libraries and ValueSets
2. "starter Questionnaire"
- URL in `Questionnaire.basedOn` is used by Adaptive Questionnaire Service’s Endpoint logic to decide which questions to ask.
- It contains no items since it is initiating the adaptive form.
- >NOTE: for adaptive questionnaires, there will be no ValueSets and may not be any Libraries as CQL is typically in-line and questions - when they appear - will only provide answerOptions, not value sets. :thinking_face: What about getting data requirements to evaluate the CQL.

@startuml

    "DTR App" -> "Payer" : POST $questionnaire-package
    "Payer" --> "DTR App": Return Questionnaire\n(or QuestionnairerResponse w/contained Questionnaire)\n, Libaries, and ValueSets
@enduml

## :thinking_face: What Triggers the DTR App to Load the initial “empty” QuestionnaireResponse to the Adaptive Questionnaire Service’s Endpoint?
:raised_hand:
- The Questionnaire Adaptive Extension

@startuml

alt Questionnaire Adaptive Extension present

group Adaptive Form

    "DTR App" -> "Adaptive Questionnaire Service" : POST $next-question for next question
end

else Questionnaire Adaptive Extension absent
group Static Form
    "DTR App" -> "DTR App": Evaluate CQL
    "DTR App" -> "DTR App": Prepopulate Questionnaire
end
end
 
@enduml

:::spoiler **Click to see interaction for Initiating an Adaptive Questionnaire**

**Request**

`POST [base]/Questionnaire/$next-question`

Payload

{%gist Healthedata1/c2cbd823a6373906bcc7836fbb170daa %}

**Response**

Headers

~~~
HTTP/1.1 200 OK
...(other headers)
~~~

Body

{%gist Healthedata1/b5ba9d24dd072097f6bfcb069fa38523 %}

:::

## :thinking_face: Next Steps

### Complete the Adaptive Form

Each Question is answered by the DTR App - either prepopulated or by an end user - and the QuestionnaireResponse updated and the ``$next-question` operation invoked to the Adaptive Questionnaire Service’s Endpoint for the next question. This cycle is repeated until the Adaptive Questionnaire Service updates the QuestionnaireResponse.status from "in-progress" to completed".

@startuml

loop Until the Adaptive Questionnaire Service\nupdates the QuestionnaireResponse.status\nfrom “in-progress” to completed"
alt Pre-population

    "DTR App" -> "DTR App": Fetch Resources (x-fhir-query)
    "DTR App" -> "DTR App": Evaluate CQL (FHIRPath)
    "DTR App" -> "DTR App": Prepopulate Questionnaire
    "DTR App" -> Practitioner: Manual Review
    Practitioner --> "DTR App"
else Manual completion
    "DTR App" -> Practitioner: Completion of Question
    Practitioner --> "DTR App"
end

    "DTR App" -> "Adaptive Questionnaire Service" : POST $next-question for next question
end
    
@enduml

### DTR Updates the Task and POSTs 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.

DTR App->Provider: POST QuestionnaireResponse
note over DTR App: When QuestionnaireResponse is complete
DTR App->Provider:  Update Task to "completed"  and reference\nthe QuestionnaireResponse in Task.output

:::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 Adaptive Questionnaire)

{%gist Healthedata1/1d9b6d4ce34a691ea8a41aa52e40dd7c %}

*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)
~~~

:::

### CDEX Submits 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

CDEX->Payer: POST $submit-attachment with\n QuestionnaireResponse as payload

:::spoiler **Click to show the `$submit-attachment` Operation interaction details**

#### Provider Invokes Operation on Payer's Server

~~~
POST [base]/$submit-attachment
~~~

##### Payload

{%gist Healthedata1/1d9b6d4ce34a691ea8a41aa52e40dd7c %}

*Response Headers*

~~~
HTTP/1.1 200 OK
...(other headers)
~~~

:::

## :thinking_face: Issues with DTR documentation on Adaptive Forms

([source](http://build.fhir.org/ig/HL7/davinci-dtr/specification.html#questionnaire-rendering))

1. >This interactivity means that it is possible for a payer to provide a Service Coverage Determination along with the QuestionnaireResponse

:Question: how does this work exactly - In the Questionnaire as an item (like a score ... e.g., You passed!!!) ?

1. >The only CQL needed in the Questionnaire is that needed to support populating question answers

:Question: how is different from a static pre-populated Questionnaire? ( this is at least poorly worded )

1. :Question: Are there any changes needed in CDex to accomodate DTR using adaptive forms?

:raised_hand: No - the adaptive forms interactions are isolated to DTR.

1. Which actor is responsible for which FHIR Artifacts and Service?

1. >NOTE: for adaptive questionnaires, there will be no ValueSets and may not be any Libraries as CQL is typically in-line and questions - when they appear - will only provide answerOptions, not value sets.
- :thinking_face: What about getting data requirements to evaluate the CQL for each question, DTR says that you need a Library to fetch them.

|Artifact/Service|Actor|Comment
|---|---|---|
|Task|Payer||
|Initial QuestionnaireResponse|Payer|fetched via `$questionnaire-package`|
|Adaptive Questionnaire Server|Payer|reached via `$next-question`|
|Library (cql),ValueSets,CodeSystems|Payer||
|Update QuestionnaireResponse|Provider|via DTR|
|Submit completed QuestionnaireResponse to Payer|Provider|CDEx via `$submit-attachment`|