MedMij FHIR Implementation Guide: Questionnaire and Questionnaire Response (Vragenlijsten)
Work in progress - See official publication here.
- 1 Introduction
- 2 Actors involved
- 3 Boundaries and Relationships
- 4 Use case: retrieve questionnaire
- 5 Use case: send questionnaire response
- 6 Handling errors
- 7 Interactions, operations, search parameters
This page describes the exchange of Questionnaires and Questionnaire Responses within MedMij. Contrary to other use cases for MedMij, no existing information standards nor specific HCIM models have been identified. To achieve exchange of Questionnaire and Questionnaire Response, MedMij adopts as much as possible from existing standards, such as the Structured Data Capture (SDC) profiles using HL7 FHIR STU3 resources. A Questionnaire is an organized collection of questions intended to solicit information from patients, providers or other individuals involved in the healthcare domain. They may be simple flat lists of questions or can be hierarchically organized in groups and sub-groups, each containing questions. The Questionnaire defines the questions to be asked, how they are ordered and grouped, any intervening instructional text and what the constraints are on the allowed answers. The results of a Questionnaire can be communicated using the QuestionnaireResponse resource. To provide a reference to the Questionnaire the FHIR Task resource is used by which a practitioner can assign a Questionnaire to the patient.
The specification currently consists of use cases, that cover provisioning a questionnaire to a patient by a healthcare provider and a patient returning a questionnaire response.
2 Actors involved
Table 1 shows the relevant actors, systems and FHIR capability statements in MedMij context. The capability statements demonstrate the minimum requirements to be conformant to 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. Questionnaires MAY be stored at XIS or at Questionnaire Repository outside XIS. That means the role of XIS in table 1 MAY also be supported by Questionnaire Repository. Any notifications (e.g. when a questionnaire is assigned to a patient) or retrieving a questionnaire are not covered by this specification.
|Actors||Systems||FHIR Capability Statements|
|Patient||The user of a personal healthcare environment retrieves a questionnaire reference Task||PHR||Personal health record||CapabilityStatement: Client Gets Questionnaire Reference||FHIR Client requirements|
|Patient||The user of a personal healthcare environment retrieves a questionnaire.||PHR||Personal health record||CapabilityStatement: Client Gets Questionnaire||FHIR Client requirements|
|Patient||The user of a personal healthcare environment provides a questionnaire response.||PHR||Personal health record||CapabilityStatement: Client Provides QuestionnaireResponse||FHIR Client requirements|
|Healthcare professional||The user of an XIS provides a Questionnaire Reference Task.||XIS||Healthcare information system||CapabilityStatement: Server Provides Questionnaire Reference Task||FHIR Server requirements|
|Healthcare provider||The healthcare provider provides a Questionnaire.||XIS||Healthcare information system||CapabilityStatement: Server Provides Questionnaire||FHIR Server requirements|
|Healthcare provider||The healthcare information system accepts creation of a QuestionnaireResponse.||XIS||Healthcare information system||CapabilityStatement: Server Accepts QuestionnaireResponse||FHIR Server requirements|
Table 1. Actors, systems and FHIR capability statements
3 Boundaries and Relationships
The MedMij use case for Questionnaire and Questionnaire Response has similarities and differences with SDC use cases. Wherever possible every attempt is made to re-use the SDC profiles. The MedMij derived profiles reference HCIM based profiles for common resources like Patient, Practitioner, PractitionerRole and Organization. The author of the questionnaire response tells who the person is who provided the answers to the questions in the QuestionnaireResponse. For the current Medmij use case it may be a patient. The subject of the questionnaire response 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 Questionnaire Reference Task. The PHR gets the reference to Questionnaire and the Questionnaire can be retrieved. The patient can answer the questions which will be provide by Questionnaire Response. After the patient is done with Questionnaire Response the Task will be closed. This FHIR implementation guide assumes that the PHR system is able to make a connection to the XIS or Questionnaire Repository to retrieve a questionnaire. It does not provide information on finding the right XIS or Questionnaire Repository nor does it provide information about security. These infrastructure and interface specifications are described in the 'Afsprakenstelsel'.
4.1.1 Client Gets Questionnaire Reference - PHR
The PHR system provides a Task containing a reference to the patient questionnaire using a search operation. The Task SHALL conform to the MedMij questionnaire reference task profile. A search interaction can be performed by an HTTP GET or command as shown:
The Task SHALL be closed (Task.status is set to 'closed') when the QuestionnaireResponse is created and can be received by the requesting practitioner.
4.1.2 Client Gets Questionnaire - PHR
The PHR system retrieves the questionnaire assigned to patient using read operation. The Questionnaire SHALL conform to the MedMij questionnaire profile. A read interaction MAY be based on the reference for the Questionnaire found in the Task.focus element but MAY also be obtained through other means outside the scope of this specification.
5 Use case: send questionnaire response
5.1 List of invocations
This FHIR implementation guide assumes that the PHR system is able to make a connection to the XIS to send questionnaire response. 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 'Afsprakenstelsel'.
5.1.1 Client Provides QuestionnaireResponse - PHR
Recording answers to questions in the questionnaire is done in an instance of QuestionnaireResponse. Upon completion the PHR system provides this questionnaire response to the XIS. The QuestionnaireResponse SHALL conform to the MedMij questionnaire response profile. A create interaction can be performed by an HTTP POST or command as shown:
Important section of the FHIR specification for a server in this use case is the create
If the questionnaire response succeeds, the server SHALL return 201 Created HTTP status code and SHALL also return a Location header which contains the new Logical Id and Version Id of the created resource version.
Note: updating the QuestionnaireResponse is not supported in the use case.
6 Handling errors
If the search fails (cannot be executed, not that there are no matches), the return value is a status code 4xx or 5xx with an OperationOutcome. An HTTP status code of 403 signifies that the server refused to perform the search, while other 4xx and 5xx codes signify that some sort of error has occurred. The HTTP status code 404 is returned if a XIS did not implement an endpoint used in a request by a PHR. When the search fails, a server SHOULD return an OperationOutcome detailing the cause of the failure. For example, in case of a not implemented FHIR endpoint, the OperationOutcome would state that the resource type is not supported. Note: an empty search result is not a failure.
Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):
- 400 Bad Request - search could not be processed or failed basic FHIR validation rules
- 401 Not Authorized - authorization is required for the interaction that was attempted
- 404 Not Found - resource type not supported, or not a FHIR end-point
In some cases, parameters may cause an error. For instance:
- A parameter may refer to a non-existent resource.
- A parameter may refer to an unknown code
- A parameter may refer to a time that is out of scope
- A parameter may use an illegal or unacceptable modifier
- A date/time parameter may have incorrect format
- A parameter may be unknown or unsupported
Where the content of the parameter is syntactically incorrect, servers SHOULD return an error. However, where the issue is a logical condition (e.g. unknown subject or code), the server SHOULD process the search, including processing the parameter - with the result of returning an empty search set, since the parameter cannot be satisfied.
In such cases, the search process MAY include an OperationOutcome in the search set that contains additional hints and warnings about the search process. This is included in the search results as an entry with search mode = outcome. Clients can use this information to improve future searches.
Link to relevant FHIR specification: http://hl7.org/fhir/STU3/search.html#errors
7 Interactions, operations, search parameters
The following logical interactions are needed for the use case of Questionnaire and Questionnaire Response:
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.
- Populate Questionnaire
- Generate HTML for Questionnaire
- Generate a link to a Questionnaire completion webpage
- Build Questionnaire
7.3 Search parameters
The following search parameter types and search result parameters need to be supported for this use case.
Search parameter types:
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|