2022 - 09 Questionnaire

Short Description

Questionnaires and forms permeate healthcare.  This track will continue testing implementation of the US Core Questionnaire profiles, the Structured Data Capture (SDC) implementation guide and the Patient Reported Outcomes (PRO) implementation guide, which all provide guidance on how to define and complete questionnaires in healthcare, including the ability to automatically populate forms and the ability to extract resource information from completed forms.

Long Description

Track objectives include:

• Representing a wide variety of forms using FHIR and verifying that the SDC implementation guide supports the needed representation capabilities, including flow control logic and calculations
• Testing authoring application abilities to create and edit such forms
• Test the ability of questionnaire completion tools abilities to handle different types of forms
• Test the ability of applications to automatically complete forms using existing data
• Test the ability of systems to handle rendering 'adaptive' forms (forms where a third-party system decides on the next question based on prior answers)
• Ideally, test some of the new language translation mechanisms we've been exploring on the 

Type

Test an Implementation Guide

Track Lead(s)

Lloyd McKenzie

Paul Lynch

Brian Postlethwaite

Track Lead Email(s)

lloyd.mckenzie@accenture.com plynch@nih.gov brian_pos@hotmail.com 

Specification Information

Leverages:

• http://build.fhir.org/ig/HL7/sdc (published version: https://hl7.org/fhir/uv/sdc/stu3/index.html)
• http://fhir.org/guides/argonaut/questionnaire/1.0.0/

Call for participants

Anyone interested in the design of forms or in tooling that supports the population of forms and use of information so gathered.  This is an international track.  Participants from other tracks that make use of Questionnaires as part of their IG are welcome to hang out with us when they have time too

Prerequisites

1. Have read through the SDC IG
2. Have an understanding of how FHIR works
3. Have one of:
   1. a functioning development environment with code that implements one of the roles listed below and can participate in at least one of the test scenarios
   2. an example instance authoring environment and one or more pre-crafted instances of Questionnaires or QuestionnaireResponses that can be used to test other systems
   3. some other agreed functionality discussed with the track lead that should support development of the IG and/or testing of other participants' software

Zulip stream

https://chat.fhir.org/#narrow/stream/179255-questionnaire

Wednesday, Sept. 14 at 5:30pm Eastern.  Call details are at https://www.hl7.org/concalls/CallDetails.cfm?concall=59433.

Recording: https://hl7-org.zoom.us/rec/share/8G7hMLVQnRst48cnXHEF46MxtmjVc_TLBVc4S_1exyGFknyFpeq1UiPXC9gIlq3Q.QRKpo1Fnp3aLpZxO

9/17  9 a.m.:  Introductions & track planning

9/17 10 a.m.:  SDC IG in-depth walk-through (see attachments for slides)

9/18: 2 p.m.:  Demos of Questionnaire-related tools or of track progress

Testing Scenario:

System Roles used in the scenarios

Note that software for many of these roles is already written (see "Software and Servers" below), so you can try scenarios involving roles you have not written yourself.

Role 1 - Forms Repository Server  (SDC Form Manager)

A server that holds the FHIR Questionnaires to be used for rendering and pre-population (forms should have the SDC pre-population information in them)

Role 2 - Data Provider

A FHIR Server that provides data for use in the pre-population of a form, and also clinical context (preferably through smart on fhir app launch)

For best results the server should also support the search batch processing, reducing the number of calls to the server to retrieve data to populate with.

Role 3 - Populate Server

A server that implements the SDC $populate operation, with FHIRPath or Observation based data extraction processing.  Note that Form Renderers (see below) may handle population as well, so population can be either done server-side or client-side.

Role 4 - SDC Form Receiver

A server that will receive a FHIR QuestionnaireResponse that has been submitted by a user, and subsequently validated.

Role 5 - Form Renderer  (SDC Form Filler)

A user interface for displaying a Questionnaire/Questionnaire response, permitting a user to complete the form and submit the answers.

Role 6 - SDC Form Designer 

Tools that build and edit form definitions.

Software & Servers

• SDC Implementations: Includes software for "Form Designer", "Form Filler (Renderer)", and Populate Server
• Public Test Servers: For "Form Repository Server", "Data Provider", and "Form Receiver"

Scenarios

The following are some suggested scenarios to try.  Feel feel to make up your own to exercise other interesting areas of the SDC Implementation Guide.

Scenario 1 - Create a new Form with Observation or Expression-based pre-population fields inside

This will be used to get experience creating forms, including data extraction information, and fhirpath expressions

Action: Create a new form and save it to a FHIR Server (Such as the Telstra Health Test Server - which will validate the definition)

Precondition: (none)

Success Criteria: Form was able to validate and be used by a populate server, retrieving data from several FHIR Servers (PMS)

Bonus point: Search bundle was external to the form

Bonus point: Data extraction includes multiple launch contexts

Bonus point: Multiple queries in the search bundle

Bonus point: Multiple groups with complex fhirpath extract expressions

Scenario 2 - Provide data for pre-population based on a Search Bundle 

Action: Return the results a search for data as defined by a form pre-population definition

Precondition: A Form with pre-populate rules, a context to perform the searching

Success Criteria: able to return the results of the search

Bonus point: able to handle a bundle as well as individual search interactions

Scenario 3 - Perform a pre-population of provided form

Action: Implement the fhirpath based $populate operation

Precondition: A form definition with fhirpath based data extraction rules in it, and the set of required resources to complete the population (data context)

Success Criteria: A draft QuestionnaireResponse resource is created with all the answers as completed 

Bonus point: pre-populate a definition with repeating sections

Bonus point: pre-populate a definition with multiple search bundle queries

Scenario 4 - Validate a form provided by a user that has been pre-populated

Action: perform QuestionnaireResponse validation against a defined Questionnaire definition, including SDC extenions.

Precondition: A form that has SDC validation extensions in it

Success Criteria: The basic FHIR validations, and Questionnaire Type validations are performed

Bonus point: SDC extensions are reported

Bonus point: SDC complex validation extensions are reported

Scenario 5 - Render a form with data that has been been pre-populated

Action: Ability to render the QuestionnaireResponse, and then submit it to a designated location (for validation etc)

Precondition: A QuestionnaireResponse with completed answers in it.

Success Criteria: Each completed answer should display with the data as extracted, and SDC extensions should also be honored, specifically enable when.

Bonus point: Fhirpath based enable when logic

Scenario 6 - Terminology questionnaire choice column extension

When using questionnaire-choiceColumn to indicate additional columns to show for an item's answerValueSet, there are some challenges in R4 around getting the data for the additional columns.  It looks like you first need to do an $expand (maybe with filter) to get a list of N items, and then do an additional N CodeSystem $lookup queries to get the properties requested by the questionnaire-choiceColumn instances for each item.  In R5, the properties can be requested with the $lookup, so it will be easier.   The task here would be to see if the answer list can be rendered reasonably quickly in R4.

https://chat.fhir.org/#narrow/stream/179255-questionnaire/topic/questionnaire-choiceColumn

Scenario 7 - AnswerExpression as another alternative to answerOption or answerValueSet

Under some scenarios you need to have a more dynamic set of options than are possible to define with a static set, this extension permits you to provide an expression to define that set of possible values.

Examples:

• https://sqlonfhir-r4.azurewebsites.net/fhir/Questionnaire/coding-sampler
• https://lforms-fhir.nlm.nih.gov/baseR4/Questionnaire/rxterms
• https://github.com/lhncbc/lforms/blob/master/test/data/answerExpressionTest.json

Scenario 8 - Observation-based extraction

Create an Questionnaire in which some questions are marked for extraction into Observation resources.  Write or use a tool to do the extraction.

Scenario 9 - StructureMap-based extraction

Write a Questionnaire and a StructureMap for extracting data from it, or write the code that implements the $extract operation.

TestScript(s)

None at this point, however will have a test service available for all roles, that you can switch various roles for testing, or provide your own questionnaires too.  If someone wants to write TestScripts, they'd be welcome 

Security and Privacy Considerations

No expectation for OAuth or TLS in the test environment (though such technologies might well be needed in a production environment)