- Created by Lloyd McKenzie, last modified by Paul Lynch on Sep 18, 2022
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.
Track objectives include:
Test an Implementation Guide
Track Lead Email(s)
firstname.lastname@example.org email@example.com firstname.lastname@example.org
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
|Track Kick off Call|
Wednesday, Sept. 14 at 5:30pm Eastern. Call details are at https://www.hl7.org/concalls/CallDetails.cfm?concall=59433.
|Track Scheduled Events|
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
|Clinical Input Required?||Clinical use-cases are welcome. Clinicians to help exercise form filler tools are also welcome|
|Related Tracks?||TBD (Da Vinci Burden Reduction, Gravity, possibly some Vulcan or public health tracks)|
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)
post Connectathon feedback - I really appreciated the discussions with Paul Lynch and Lloyd McKenzie during this track, as well as the SDC IG discussion Ravi Kafle and I had w/ Lloyd to understand some of the thinking behind the IG. Also, great discussions with Vadim Peretokin and Greg, and others who stopped by to talk ICHOM, & other topics. A small track, perhaps, but a very valuable one for me!
Agreed! Great to meet you Bill Lober to discuss the PRO work you're doing, and a big thank you Paul Lynch and Ye Wang for your support with LHCForms!