Questionnaire MOPED UseCase

Short Description

This track introduces questionnaire-based reporting workflows in the Austrian MOPED project using FHIR Questionnaires and QuestionnaireResponses. Participants will load Questionnaires from the Implementation Guide, render and complete them using browser-based tools, submit QuestionnaireResponses to a FHIR server, and explore questionnaire versioning and lifecycle management for evolving reporting requirements.

Long Description

This track demonstrates how FHIR Questionnaires are used for structured reporting workflows within the Austrian MOPED project, including LKF statistical annual reporting by hospitals and registry reporting scenarios such as the GÖG Stroke Register.

Participants will work with real Questionnaires published in the MOPED Implementation Guide. Using browser-based rendering tools, they will explore questionnaire structure and dynamic behaviour, complete forms, generate QuestionnaireResponses, and submit them to a FHIR server. The track focuses on understanding how questionnaire-driven workflows enable standardized and reusable data collection without requiring custom UI development.

In addition, participants will explore how updated versions of Questionnaires can be automatically retrieved and rendered when reporting requirements change, enabling version-specific data capture over time.

An experimental level introduces advanced workflows based on the HL7 Structured Data Capture (SDC) specification, including the $populate operation. This demonstrates how existing data can be used to prefill QuestionnaireResponses via REST clients such as Postman, reducing manual data entry and supporting more automated reporting processes.

Overall, the track provides a practical introduction to questionnaire lifecycle management, structured reporting, and evolving form-based workflows in real-world healthcare settings.

Type

Submitting Work Group/
Project/
Accelerator/
Affiliate/
Implementer Group  

AG Moped

Track Lead(s)

Anja Schwab, Sebastian Wöß

Track Lead Email(s)

tc-fhir@hl7.at

Related Tracks

https://hl7at.atlassian.net/wiki/x/AYCKOw (in case the basics are required)

FHIR Version

All related IGs:

• FHIR R5

Specification(s) this track uses

https://fhir.hl7.at/r5-ELGA-MOPED-main/index.html

https://hl7.org/fhir/index.html

Experimental: https://hl7.org/fhir/uv/sdc/

Artifacts of focus

• Questionnaire R5 https://hl7.org/fhir/questionnaire.html

• QuestionnaireReponse R5 https://hl7.org/fhir/questionnaireresponse.html

Date / Time

Monday March 2nd, 09:00am-17:00pm CET

Test Servers

HAPI FHIR R5: https://hapi.fhir.org/baseR5

Pine IT R5: https://hackathon-r5.pineit.at/pineit/pitdata-fhir/fhir

• Basic Auth required (ask track lead for details)

Expected participants

This track is aimed at participants who want to explore how FHIR Questionnaires can be used for structured reporting workflows in healthcare administration and registries.

The primary audience includes stakeholders and implementers involved in:

• LKF statistical annual reporting by Austrian hospitals

• registry reporting processes (e.g., the GÖG Stroke Registry)

Prior programming experience is not required, but participants should be interested in understanding how questionnaire-driven data exchange works in real-world reporting scenarios.

Track Details

Pre-Requisites

• REST-Client (Postman, Insomnia, and/or Bruno)

• Browser

Scenarios

Within the MOPED (Moderne Patient:innenabrechnung und Datenkommunikation on FHIR) project, Questionnaires are used to model structured reporting forms such as LKF annual reports and medical registry submissions.

Participants will work with real Questionnaires provided via the MOPED Implementation Guide.

The workflow consists of:

1. Loading Questionnaire definitions from the MOPED IG

2. Rendering the Questionnaire using an online Questionnaire renderer (e.g., a browser-based tool)

3. Filling out the Questionnaire via the UI

4. Generating a QuestionnaireResponse

5. Copying and submitting the QuestionnaireResponse to a FHIR server

This workflow demonstrates how structured reporting can be implemented without building a custom UI from scratch.

Participants will learn:

• how Questionnaires are published and retrieved from an Implementation Guide

• how Questionnaire rendering tools transform definitions into interactive forms

• how user input is represented as a QuestionnaireResponse

• how QuestionnaireResponses are submitted to FHIR servers

• experimental: how preexisting FHIR data can be used to prefill forms

Success Criteria

Participants successfully complete the track when they can:

• load a Questionnaire from the MOPED Implementation Guide

• render and complete it using a browser-based tool

• generate a valid QuestionnaireResponse

• submit the response to a FHIR server

Level 1 – Guided / Click-Through

As a first step, explore how LKF statistical data Questionnaires are defined in the Implementation Guide (IG).

An explicit example is the LKF K04 Questionnaire, available here as JSON: https://fhir.hl7.at/r5-ELGA-MOPED-main/Questionnaire-LKFK04Questionnaire.json.html

Step 1 — Explore the Questionnaire

The Questionnaire can be viewed using an online renderer to better understand how the JSON definition translates into a real form.

One example renderer is: https://fhirpath-lab.com/Questionnaire/tester

Inside the tester:

• insert the Questionnaire JSON

• switch to LHC Forms

• view the fully rendered UI version of the Questionnaire

• fill in example answers for a concrete response

The renderer already supports client-side validation, so many incorrect inputs are detected directly while entering data. When clicking “Show Response”, you will receive a generated QuestionnaireResponse JSON, which will be used later in Postman.

Step 2 — Work with the prepared Postman collection

Switch to the prepared Postman collection.

You will find:

• a valid K04 example containing sample data

• a $validate request demonstrating server-side validation

Running $validate confirms that no issues were detected in the QuestionnaireResponse.

A second example replaces values with “TBD.”

This serves as a template:

• participants fill in their own values directly in the JSON

• clicking Send validates the resource again

• server-side validation feedback shows how the server reacts to the entered data

Step 3 — Validation vs. Persistence

Important to understand:

• POST $validate does not change server state

• no resource is created, even if validation succeeds

To actually store data on the server, the next request performs a POST of the QuestionnaireResponse.

Step 4 — Retrieve the created resource

After posting:

• check the Response Headers in Postman

• look for the Location header

This header contains the path where the newly created QuestionnaireResponse can be retrieved.

Participants should:

• copy the path

• perform a GET request

• retrieve the created resource from the server

Step 5 — Versioning and History

Next, modify the created QuestionnaireResponse (for example by changing one value) and upload a new version.

Afterwards you can:

• query _history to see all versions of the resource

Step 6 — Performing Queries

• perform a general read of all QuestionnaireResponses

• filter results using search parameters defined in the FHIR specification: https://hl7.org/fhir/questionnaireresponse.html#search

Level 2 – Apply the Learned Pattern

In this level, participants apply the same workflow learned in Level 1 to a new Questionnaire.

Instead of using the prepared example, you will load a different statistical LKF Questionnaire from the MOPED Implementation Guide and repeat the same pattern end-to-end: https://fhir.hl7.at/r5-ELGA-MOPED-main/index.html#

The goal is to reinforce the basic workflow while showing that the process is reusable across different Questionnaires.

Participants will:

• retrieve a statistical Questionnaire from the MOPED IG

• POST the Questionnaire to the FHIR server

• create and validate a corresponding QuestionnaireResponse

• POST the QuestionnaireResponse back to the server

• Query the QuestionnaireResponses of interest

Level 3 – Prefilling Forms (Experimental)

This experimental level introduces automated pre-population of FHIR Questionnaires using the $populate operation defined in the HL7 Structured Data Capture (SDC) specification.

The main goal is to reduce manual data entry by automatically inserting already available clinical or administrative data into a Questionnaire before it is completed.

Instead of working with a rendered UI, participants interact directly with the FHIR API using tools such as:

• Postman or other REST clients

In the provided Postman collection, we created a custom Questionnaire called “FancyK04”

This Questionnaire already contains predefined mapping paths in its template.
As a small example, it extracts the value of an Organization identifier that uses the system representing the KA number.

This is intentionally a minimal example showing how you can centrally define, directly in the Questionnaire, which FHIR elements should appear in the response.

The exact same concept can be applied to many other resources, for example:

• Practitioner → author details

• Patient → questionnaire subject or demographic data

• Organization → administrative identifiers (e.g., KA number)

• Condition, Observation, and other clinical resources

What happens when you call $populate:

When $populate is called with the appropriate context parameters, the server generates a QuestionnaireResponse where all fields that can be resolved via the paths defined in the Questionnaire are already prefilled.

This initial population provides a strong starting point:

• known data is filled in automatically

• unknown or missing information can still be completed manually

• overall click effort is reduced

Try it yourself

Experiment with the setup:

• Create or POST an Organization with any KA number you like.

• Reference that Organization in the context parameter of your $populate request.

• Observe how the returned QuestionnaireResponse changes depending on the context — you should see a different KA number filled in automatically each time.

You can also modify the FancyK04 Questionnaire itself (please in that case use a different ID for your Questionnaire):

• instead of the KA number, try mapping the Organization name or OID

• adjust the defined paths and see how the generated QuestionnaireResponse changes

This helps you understand how the Questionnaire design directly controls what data gets prefilled.

Helpful Links

Security and Privacy considerations

Do not submit personal data (in particular, social insurance numbers and the like). Development and Test clusters require authentication, but are not encrypted and hardened like a production instance would be - use only the provided pseudo certificates.