- Created by Lloyd McKenzie, last modified on Apr 21, 2023
Questionnaires and forms permeate healthcare. This track will continue testing implementation of the Structured Data Capture (SDC) implementation guide which all provides 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.
Ongoing track objectives include:
New new functionality we're hoping to test this time around includes:
Test an Implementation Guide
The following IGs leverage Questionnaire and/or QuestionnaireResponse and have some alignment with the SDC IG:
Call for participants
This track is appropriate to 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
Track Lead Email(s)
Track Kick off Call
Thursday, Apr. 20, 5:00 Eastern. https://hl7-org.zoom.us/j/8583747934?pwd=VnZiWFZsNm1TSk5QWmZlbVJyQVZGdz09
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
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)
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.
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.
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.
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)