{{#customtitle:MedMij FHIR Implementation Guide: Questionnaire and Questionnaire Response (Vragenlijsten)}} MedMij:Vdraft Issuebox FHIR IG

1 Introduction

This page describes the exchange of questionnaires and questionnaire responses within MedMij. A questionnaire is an organized collection of questions intended to solicit information from patients, providers or other individuals involved in the healthcare domain. These questionnaires may take the form of a straightforward flat list of questions, but they can consist of hierarchically organized groups and sub-groups. Likewise, there can be a wide range of question types, varying from simple fill-out forms to multiple choice questions and scales.

These questionnaires are captured using the FHIR Questionnaire resource, which defines the questions to be asked, their ordering and grouping, instructional text and the constraints on the answers. The results of a Questionnaire can be communicated using the QuestionnaireResponse resource. To support the logistics of assigning and answering a questionnaire, a Task resource is used.

This information standard is inspired by the international Structured Data Capture (SDC) implementation guide and tries to follow it where possible. However, the first version of this information standard is more restricted than SDC; specifically, the possibility for a XIS to pre-populate the questionnaire response is omitted in this first version. Also, contrary to most other use cases for MedMij, no specific HCIM models have been identified for prescribing and answering questionnaires.

Note: this page is part of the MedMij FHIR Implementation Guide and is a technical representation of the functional design published on this wiki page.

2 Actors involved

Table 1 shows the relevant actors, systems and FHIR Capability Statements in MedMij context. The Capability Statements demonstrate the minimum conformance requirements for the described use cases. The role that covers the provision of a Questionnaire MAY be integrated in the XIS or MAY be supported by a separate questionnaire repository. That means the role of XIS in table 1 MAY also be supported by a questionnaire repository.

Note: according to the MedMij Afsprakenstelsel, the PGO initiates communication with the XIS, not the other way around. Therefore, the healthcare provider needs to inform the patient about the questionnaire offline. The PGO should provide an interface to the user to manually check a specific healthcare provider for questionnaire tasks. (TODO: hoort dit hier thuis of in FO?)

Actors		Systems		FHIR Capability Statements
Name	Description	Name	Description	Name	Description
Patient	The user of a personal healthcare environment	PHR	Personal health record retreives a task retreives a questionnaire updates the task sends the questionnaire response	CapabilityStatement: Client	FHIR Client requirements
Healthcare professional	The user of a XIS	XIS	Healthcare information system provides a QuestionnaireReferenceTask receives updates to the task receives the questionnaire response	CapabilityStatement: Server	FHIR Server requirements
Questionnaire repository	The healthcare provider provides a Questionnaire.	VRE	Healthcare information system or third party FHIR server provides Questionnaire resource in XML and JSON formats	CapabilityStatement: Questionnaire repository	Questionnaire repository requirements

Table 1. Actors, systems and FHIR Capability Statements

3 Boundaries and Relationships

The MedMij use case for questionnaires overlaps partially with the uses cases described in the Structured Data Capture (SDC) IG. Therefore, this IG tries to align as close as possible to the SDC IG. However, there are key differences that prevent the use of the SDC IG verbatim:

the current use case is more restricted
the derived profiles for the MedMij use case reference HCIM based profiles for common resources like Patient, Practitioner, PractitionerRole and Organization
the interpretation of mustSupport and the use of isModifier in SDC differs fundamentally from other MedMij IG's.

The QuestionnaireResponse.author tells who the person is that provided the answers. For the current MedMij use case it may be a patient. The QuestionnaireResponse.subject tells who the answers apply to. For the current MedMij use case it may be a patient, organization or practitioner.

4 Use case: retrieve questionnaire

4.1 List of invocations

The order of invocations follows the Functional Design. At first the questionnaire is assigned to the patient by a QuestionnaireReferenceTask resource. The PHR extracts the reference to the Questionnaire resource and retrieves it from the XIS or from an external questionnaire repository.

This FHIR implementation guide assumes that the PHR system is able to make a connection to search Task resources at the XIS. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the 'MedMij Afsprakenstelsel'.

4.1.1 Client gets Questionnaire reference - PHR

Using a search operation, the PHR provides a Task resource containing a reference to the patient questionnaire from the XIS. The Task SHALL conform to the MedMij QuestionnaireReferenceTask profile SHALL initially have Task.status set to "requested" (see #Task state machine). The Questionnaire resource SHALL be referenced using Task.input.valueReference.reference.

GET [base]/Task/?status=requested&_include=Task:patient&_include=Task:requester

If the search operation fails (cannot be executed, not that there are no matches), the return value is a status code 4xx or 5xx with an OperationOutcome (see the FHIR documentation on search).

4.1.2 Client gets Questionnaire - PHR

Upon retreiving the Task, the PHR system retreives the Questionnaire resource referenced in the Task using a read operation. This reference may live on the same base as the XIS or may be an external reference.

GET Task.input.valueReference.reference.value

The Questionnaire resource SHALL conform to the MedMij Questionnaire profile.

Note: for known questionnaires, a PHR may choose to use hardcoded instead of generated forms. However, PHRs implementing this information standard should always be able to generate a form for the minimal Questionnaire subset defined below. Also note that a known questionnaire can only be recognized by its reference in the Task; currently, no coding system exists to identify known questionnaires.

If this operation fails (after repeated attempts), the PHR should close the task with status "failed" (see #Updating the Task). This closes the Task and ends the workflow (see #Task state machine).

5 Use case: send questionnaire response

5.1 Client renders questionnaire form - PHR

The PHR should present the questions defined in the retrieved Questionnaire resource to the user, in accordance with their type, overall structure of the questionnaire, and restrictions on the answers. MedMij defines the following minimal subset of Questionnaire item types that a PHR MUST support:

Group
Display
Boolean
Decimal
Integer
Date / dateTime / time
String / text
Choice / open-choice (TODO: voorkeursweg beschrijven voor gebruik van .option ipv ValueSet-reference)
Quantity

The following elements of the Questionnaire.item element MUST be supported:

Questionnaire.item.enableWhen
Questionnaire.item.required
Questionnaire.item.option

In addition, the following extensions MUST be supported:

A PHR MAY support other Questionnaire item types as well. However, if a PHR is unable to process any one part in the Questionnaire, it MUST reject the Questionnaire altogether, see below.

5.1.1 Multiple choice questions in FHIR

Unfortunately, the FHIR core documention for the Questionnaire and QuestionnaireResponse resources is somewhat confusing and actually contains an error in the topic of multiple choice questions. This section is meant to clarify the use of multiple choice type questions in FHIR STU3.

In FHIR there are two scenarios for multiple choice questions: in the first scenario, the answer MUST come from a list of predefined options, while in the second scenario, the user MAY alternatively provide a custom answer. These two scenarios are represented in Value Set http://hl7.org/fhir/ValueSet/item-type using "choice" and "open-choice" respectively.

In a Questionnaire resource, to define a multiple choice question, item.type MUST be set to "choice" or "open-choice" -- the latter one is used for multiple choice questions where the user can provide an alternative answer not in the set of predefined options. The answer options MUST be defined using either:

the item.options element, which contains a reference to a ValueSet with the possible answers.
using one or more item.option elements, with possible answers defined as valueCode. Although the Questionnaire resource defines item.option.value[x] as a polymorphic element with multiple types, only coding is actually allowed. In the relevant profile, this element is therefore restricted to this type.

Likewise, the QuestionnaireResponse resource should capture the answer using item.answer.valueCode:

if the user selects one of the predefined answers, it should be captured in the answer using the code (and if present, system) elements of valueCode.
if the question is of type "open-choice" and the user provides an alternative answer, it should be captured using the display element of valueCode.

5.2 List of invocations

This FHIR implementation guide assumes that the PHR system is able to make a connection to update the Task resource at the XIS and send the QuestionnaireResponse resource to the XIS. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the 'MedMij Afsprakenstelsel'.

5.2.1 Client accepts or rejects the Questionnaire

Upon retrieving the Questionnaire resource, the PHR SHOULD check if it is able to present a form that completely covers all the questions and structure and subsequently update the Task resource (see #Updating the Task):

If the Questionnaire can be processed, Task.status SHALL be set to "accepted".
If the Questionnaire cannot be processed, Task.status SHALL be set to "rejected". This closes the Task and ends the process (see #Task state machine).

5.2.2 Client provides QuestionnaireResponse - PHR

The answers to the questions in the Questionnaire resource are captured using an instance of the QuestionnaireResponse resource, which SHALL conform to the MedMij questionnaire response profile. If the PHR is unable to process the user response or in some other way is unable to create a QuestionnaireResponse resource, it should close the task with status "failed" (see #Updating the Task). This closes the Task and ends the process (see #Task state machine).

Upon completion of the questionnaire by the user, the PHR system uses a transaction operation to simultaniously:

send the QuestionnaireResponse resource to the XIS.
update the Task at the XIS to set Task.output.valueReference to the QuestionnaireResponse.
update the Task at the XIS to set Task.status to "completed".

A FHIR transaction is a POST command to the XIS endpoint:

POST [base]

The body of the POST operation SHALL be a Bundle resource with Bundle.type set to "transaction" that SHALL contain

the QuestionnaireResponse resource as a create interaction
the original Task resource with the required changes in Task.status and Task.output as an update interaction (see #Updating the Task)

Example:

<Bundle xmlns="http://hl7.org/fhir">
    <type value="transaction"/>
    <entry>
        <resource>
            <Task>
                <id value="ORIGINAL_ID"/>
                <meta>
                    <profile value="..."/>
                </meta>
                <status value="completed"/>
                ...
                <output>
                    <type>
                        <text value="QuestionnaireResponse"/>
                    </type>
                    <valueReference>
                        <reference value="urn:uuid:e607a55c-194d-447a-8cc7-7ab90e3660c3"/>
                        <display value="Response to questionnaire XXX">
                    </valueReference>
                </output>
            </Task>
        </resource>
        <request>
            <method value="PUT"/>
            <url value="Task/ORIGINAL_ID"/>
        </request>
    </entry>
    <entry>
        <fullUrl value="urn:uuid:e607a55c-194d-447a-8cc7-7ab90e3660c3"/>
        <resource>
            <QuestionnaireResponse>
                <meta>
                    <profile value="..."/>
                </meta>
                ...
            </QuestionnaireResponse>
        </resource>
    </entry>
    <request>
        <method value="POST"/>
        <url value="QuestionnaireResponse"/>
    </request>
</Bundle>

If the server is able to process both resources, it SHALL return a HTTP 200 OK status code and SHALL also return a Bundle of type 'transaction-response', that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

If the server is unable to process either of the resources, it SHALL not process any one of them and SHALL return an HTTP 400 or HTTP 500 type response.

Note: updating the QuestionnaireResponse is not supported in the use case.

6 Tracking the status using the Task resource

6.1 Introduction

Retreiving the questionnaire and sending the answers are two separate use cases, but they are meant to be used back-to-back; the XIS that prescribes the questionnaire ultimately expects a response to it (and a questionnaire response is only sent in response to a prescription, at least in the current version). To track the status of the prescription fullfillment, a Task resource at the XIS server is used, which transitions through various stages until completion.

It is the responsibility of the PHR to update the task at the different stages in the life cycle of the questionnaire, using an update operation (see #Updating the Task). This implies that the the Task resource should be made accessible by the XIS server for these updates, at least for the expected life time of the fullfillment cycle. Additionally, the PHR may perform a read of the Task resource at any time.

It is primarilly the responsibility of the PHR to bring the task to a closed state. However, it is not guaranteed that the required update operation succeeds. If the PHR is unable to bring the task to a closed state, the server may eventually close the task because of business rules.

6.2 Task state machine

The Task resource can transition through the following states:

          /----------------/-------------------\
          |                |                   |
requested +--+-> accepted -+---> completed ----+---> X
          |  |             |                   |
          |  \-------------\--> failed --------|
          |                                    |
          \--> rejected -----------------------/

TODO: uittekenen.

Only the transactions shown here are allowed. The server should reject any update that attempts to perform an illegal transaction. See #Task update failures.

6.3 Updating the Task

The Task resource at the XIS can be updated by the PHR using the FHIR update operation. To perform this operation, the modified Task resource should be sent using a PUT operation:

PUT [base]/Task/ORIGINAL_ID

Where ORIGINAL_ID is the Task.id from the Task originally received from the XIS.

Note: apart from the relevant modifications, the Task resource should be sent completely and without changes.

The server may be unable to accept an update the Task resource due to errors or because of business rules (e.g. because of an illegal status transaction). In this case, the server should respond with a 400 type status code, accompanied by an OperationOutcome resource providing additional details (see the FHIR documentation on rejecting updates).

The PHR should try to recover from this response. If this is not possible, the PHR should attempt to update the status of the Task resource on the server to "failed" and stop further processing. If it is not possible to perform this task update, the task effectively remains in a stalled position. The server may eventually close it because of business rules.

7 Interactions, operations, search parameters

7.1 Interactions

The following logical interactions are needed for the use case of Questionnaire and Questionnaire Response:

Search -- Task
Update -- Task
Read -- Questionnaire
Create -- QuestionnaireResponse

7.2 Operations

The following operations have been specified for use in SDC. The MedMij use case has no identified requirement for these operations. This specification therefor does not define that system roles implement them.

7.3 Search parameters

The following search parameter types and search result parameters need to be supported for this use case.

Search parameter types:

token
- Including modifier 'in'
reference

7.4 List of StructureDefinitions

The unique FHIR profiles based on HCIM applicable in a broader context than the exchange of Questionnaire and Questionnaire Response.

FHIR Profile	FHIR Resource	HCIM NL / Concept
http://fhir.nl/fhir/StructureDefinition/nl-core-patient	Patient	Patient
http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner	Practitioner	Zorgverlener
http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole	PractitionerRole	Zorgverlenerrol
http://fhir.nl/fhir/StructureDefinition/nl-core-organization	Organization	Zorgaanbieder
http://nictiz.nl/fhir/StructureDefinition/nl-core-questionnaire	Questionnaire	Questionnaire
http://nictiz.nl/fhir/StructureDefinition/nl-core-questionnaireresponse	QuestionnaireResponse	Questionnaire Response
http://nictiz.nl/fhir/StructureDefinition/QuestionnaireReferenceTask	Task	Questionnaire Reference

Zandbak/MVPTO

Inhoud